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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document defines a call control protocol for use in the IP Multimedia (IM) Core Network (CN) subsystem 
based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP). 

The present document is appUcable to: 

- the interface between the User Equipment (UE) and the Call Session Control Function (CSCF); 
the interface between the CSCF and any other CSCF; 

the interface between the CSCF and an Application Server (AS); 

- the interface between the CSCF and the Media Gateway Control Function (MGCF); 

- the interface between the S-CSCF and the Media Resource Function Controller (MRFC) 

- the interface between the CSCF and the Breakout Gateway Control Function (BGCF); 

- the interface between the BGCF and the MGCF; 

- the interface between the BGCF and any other BGCF; and 

the interface between the CSCF and an external Multimedia IP network. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP and SDP. Where this is not possible, extensions to SIP and SDP are 
defined within the present document. The document has therefore been structured in order to allow both forms of 
specification. 

NOTE: The present document covers only the usage of SIP and SDP to communicate with the enitities of the IM 
CN subsystem. It is possible, and not precluded, to use the capabilities of GPRS to allow a terminal 
containing a SIP UA to communicate with SIP servers or SIP UAs outside the IM CN subsystem, and 
therefore utilise the services provided by those SIP servers. The usage of SIP and SDP for communicating 
with SIP servers or SIP UAs outside the IM CN subsystem is outside the scope of the present document. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 
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3 Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Newly established set of security associations: Two pairs of IPsec security associations that have been created at 
the UE and/or the P-CSCF after the 200 (OK) response to a REGISTER request was received. 

Old set of security associations: Two pairs of IPsec security associations after another set of security associations 
has been established due to a successful authentication procedure. 

Temporary set of security associations: Two pairs of IPsec security associations that have been created at the UE 

and/or the P-CSCF, after an authentication challenge within a 401 (Unauthorized) response to a 
REGISTER request was received. The SIP level hfetime of such created security associations will 
be equal to the value of reg-await-auth timer. 

Integrity protected: See 3GPP TS 33.203 [19]. Where a requirement exists to send information "integrity 

protected" the mechanisms specified in 3GPP TS 33.203 [19] are used for sending the information. 
Where a requirements exists to check that information was received "integrity protected", then the 
information received is checked for compUance with the procedures as specified in 
3GPPTS 33.203 [19]. 

For the purposes of the present document, the following terms and definitions given in RFC 1594 [20B]. 

FuUy-QuaUfied Domain Name (FQDN) 

For the piuposes of the present document, the following terms and definitions given in RFC 3261 [26] apply (unless 
otherwise specified see clause 6). 

Back-to-Back User Agent (B2BUA) 

Client 

Dialog 

Final response 
Header 
Header field 
Loose routeing 
Method 

Option-tag (see RFC 3261 [26] subclause 19.2) 

Provisional response 

Proxy, proxy server 

Redirect server 

Registrar 

Request 

Response 

Server 

Session 

(SIP) transaction 
Stateful proxy 
Stateless proxy 

Status-code (see RFC 3261 [26] subclause 7.2) 
Tag (see RFC 3261 [26] subclause 19.3) 
Target Refresh Request 
User agent client (UAC) 
User agent server (UAS) 
User agent (UA) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [2] 
subclause 4.1.1.1 and subclause 4a.7 apply: 
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Breakout Gateway Control Function (BGCF) 
Call Session Control Function (CSCF) 
Home Subscriber Server (HSS) 
Media Gateway Control Function (MGCF) 
Media Resource Function Controller (MRFC) 
Subscription Locator Function (SLF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [5] 
subclause 3.1 apply: 

Filter criteria 
Initial filter criteria 
Initial request 
Standalone transaction 
Subsequent request 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [7] 
subclause 4.3.3.1 and subclause 4.6 apply: 

Interrogating-CSCF (I-CSCF) 
Policy Decision Function (PDF) 
Private user identity 
Proxy-CSCF (P-CSCF) 
Public user identity 
Serving-CSCF (S-CSCF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 33.203 [19] apply: 

Protected Server Port 
Protected Client Port 

For the purposes of the present document, the following terms and definitions given in 3 GPP TR 21.905 [1] apply: 
User Equipment (UE) 

For the purposes of the present document, the following terms and definitions given in RFC 2401 [20A] Appendix A 
apply: 

Security association 

NOTE: A number of different security associations exist within the IM CN subsystem. Within this document the 
term specifically applies to the security association that exists between the UE and the P-CSCF, as this is 
the only security association that has direct impact on SIP. 

For the purposes of the present document, the following terms and definitions given in ITU-T E.164 [57] apply: 

International public telecommunication number 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



AUTN 

B2BUA 

BGCF 



Ixx 

2xx 

AS 

APN 



CCF 
CDR 
CK 
CN 



c 



A status-code in the range 101 through 199, and excluding 100 

A status-code in the range 200 through 299 

Application Server 

Access Point Name 

Authentication TokeN 

Back- to -Back User Agent 

Breakout Gateway Control Function 

conditional 

Charging Collection Function 
Charging Data Record 
Ciphering Key 
Core Network 
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CSCF 


Call Session Control Function 


DHCP 


Dynamic Host Configuration Protocol 


DNS 


Domain Name System 


DTD 


Document Type Definition 


ECF 


Event Charging Function 


FQDN 


Fully Qualified Domain Name 


GCID 


GPRS Charging Identifier 


GGSN 


Gateway GPRS Support Node 


GPRS 


General Packet Radio Service 


HSS 


Home Subscriber Server 


i 


irrelevant 


I-CSCF 


Interrogating CSCF 


ICID 


IM CN subsystem Charging Identifier 


IK 


Integrity Key 


IM 


IP Multimedia 


IMS 


IP Multimedia core network Subsystem 


IMSI 


International Mobile Subscriber Identity 


lOI 


Inter Operator Identifier 


IP 


Internet Protocol 


IPsec 


IP security 


IPv4 


Internet Protocol version 4 


IPv6 


Internet Protocol version 6 


ISC 


IP multimedia Subsystem Service Control 


ISIM 


IMS Suscriber Identity Module 


m 


mandatory 


MAC 


Message Authentication Code 


MCC 


Mobile Country Code 


MGCF 


Media Gateway Control Function 


MGW 


Media Gateway 


MNC 


Mobile Network Code 


MRFC 


Multimedia Resource Function Controller 


MRFP 


Multimedia Resource Function Processor 


PDP 


Packet Data Protocol 


PLMN 


Public Land Mobile Network 


PSTN 


Pubhc Switched Telephone Network 


n/a 


not applicable 


NAI 


Netework Access Identifier 





optional 


P-CSCF 


Proxy CSCF 


PDU 


Protocol Data Unit 


RAND 


RANDom challenge 


RES 


RESponse 


RTCP 


Real-time Transport Control Protocol 


RTP 


Real-time Transport Protocol 


S-CSCF 


Serving CSCF 


SDP 


Session Description Protocol 


SGSN 


Serving GPRS Support Node 


SIP 


Session Initiation Protocol 


SLF 


Subscription Locator Function 


SQN 


SeQuence Number 


UA 


User Agent 


UAC 


User Agent Client 


UAS 


User Agent Server 


UE 


User Equipment 


UICC 


Universal Integrated Circuit Card 


URI 


Universal Resource Identifier 


URL 


Universal Resource Locator 


USIM 


UMTS Subscriber Identity Module 


X 


prohibited 


XMAC 


expected MAC 


XML 


extensible Markup Language 
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4 General 

4.1 Conformance of IM CN subsystem entities to SIP, SDP and 
other protocols 

SIP defines a number of roles which entities can implement in order to support capabiUties. These roles are defined in 
annex A. 

Each IM CN subsytem functional entity using an interface at the Gm reference point, the Mg reference point, the Mi 
reference point, the Mj reference point, the Mk reference point, the Mm reference point, the Mr reference point and the 
Mw reference point, and also using the IP multimedia Subsystem Service Control (ISC) Interface, shall implement SIP, 
as defined by the referenced specifications in Annex A, and in accordance with the constraints and provisions specified 
in annex A, according to the following roles. 

The Gm reference point, the Mg reference point, the Mi reference point, the Mj reference point, the Mk reference point, 
the Mm reference point and the Mw reference point are defined in 3GPP TS 23.002 [2]. 

The Mr reference point is defined in 3GPP TS 23.228 [7]. 

The ISC interface is defined in 3GPP TS 23.228 [7] subclause 4.2.4. 

The User Equipment (UE) shall provide the User Agent (UA) role, with the exceptions and additional 
capabilities to SIP as described in subclause 5.1, with the exceptions and additional capabilities to SDP as 
described in subclause 6.1, and with the exceptions and additional capabilities to SigComp as described in 
subclause 8.1. The UE shall also provide the access dependent procedures described in subclause 9.2. 

- The P-CSCF shall provide the proxy role, with the exceptions and additional capabiUties to SIP as described in 
subclause 5.2, with the exceptions and additional capabilities to SDP as described in subclause 6.2, and with the 
exceptions and additional capabiUties to SigComp as described in subclause 8.2. Under certain circumstances as 
described in subclause 5.2, the P-CSCF shall provide the UA role with the additional capabilities, as foUows: 

a) when acting as a subscriber to or the recipient of event information; and 

b) when performing P-CSCF initiated dialog-release the P-CSCF shall provide the UA role, even when acting as 
a proxy for the remainder of the dialog. 

- The I-CSCF shaU provide the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.3. 

The S-CSCF shall provide the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.4, and with the exceptions and additional capabilities to SDP as described in subclause 6.3. Under 
certain circumstances as described in subclause 5.4, the S-CSCF shall provide the UA role with the additional 
capabiUties, as follows: 

a) the S-CSCF shall also act as a registrar. When acting as a registrar, or for the purposes of executing a third- 
party registration, the S-CSCF shaU provide the UA role; 

b) as the notifier of event information the S-CSCF shall provide the UA role; 

c) when providing a messaging mechanism by sending the MESSAGE method, the S-CSCF shall provide the 
UA role; and 

d) when performing S-CSCF initiated dialog release the S-CSCF shall provide the UA role, even when acting as 
a proxy for the remainder of the dialog. 

- The MGCF shall provide the UA role, with the exceptions and additional capabiUties as described in 
subclause 5.5, and with the exceptions and additional capabilities to SDP as described in subclause 6.4. 

- The BGCF shall provided the proxy role, with the exceptions and additional capabilities as described in 
subclause 5.6. 
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The AS, acting as terminating UA, or redirect server (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.1), shall 
provide the UA role, with the exceptions and additional capabilities as described in subclause 5.7.2, and with the 
exceptions and additional capabilities to SDP as described in subclause 6.6. 

- The AS, acting as originating UA (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.2), shall provide the UA 
role, with the exceptions and additional capabilities as described in subclause 5.7.3, and with the exceptions and 
additional capabilities to SDP as described in subclause 6.6. 

- The AS, acting as a SIP proxy (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.3), shall provided the proxy 
role, with the exceptions and additional capabilities as described in subclause 5.7.4. 

The AS, performing 3rd party call control (as defined in 3GPP TS 23.218 [5] subclause 9.1.1.4), shall provide 
the UA role, with the exceptions and additional capabilities as described in subclause 5.7.5, and with the 
exceptions and additional capabiUties to SDP as described in subclause 6.6. 

NOTE 1: Subclause 5.7 and its subclauses define only the requirements on the AS that relate to SIP. Other 
requirements are defined in 3GPP TS 23.218 [5]. 

- The AS, receiving third-party registration requests, shall provide the UA role, with the exceptions and additional 
capabilities as described in subclause 5.7. 

- The MRFC shall provide the UA role, with the exceptions and additional capabilities as described in 
subclause 5.8, and with the exceptions and additional capabilities to SDP as described in subclause 6.5. 

NOTE 2: Annex A can change the status of requirements in referenced specifications. Particular attention is drawn 

to table A.4 and table A. 162 for capabilities within referenced SIP specifications, and to table A. 3 17 and 
table A.328 for capabilities within referenced SDP specifications. The remaining tables build on these 
initial tables. 

NOTE 3: The allocated roles defined in this clause are the starting point of the requirements from the IETF SIP 
specifications, and are then the basis for the description of further requirements. Some of these extra 
requirements formally change the proxy role into a B2BUA. In all other respects other than those more 
completely described in subclause 5.2a P-CSCF implements proxy requirements. Despite being a B2BUA 
a P-CSCF does not implement UA requirements from the IETF RFCs, except as indicated in this 
specification, e.g., relating to registration event subscription. 



4.2 URI and address assignments 

In order for SIP and SDP to operate, the following preconditions apply: 

1) I-CSCFs used in registration are allocated SIP URIs. Other IM CN subsystem entities may be allocated SIP 
URIs. For example sip:pcscf.homel.net and sip:<impl-specific-info>@pcscf.homel.net are valid SIP URIs. If 
the user part exists, it is an essential part of the address and shall not be omitted when copying or moving the 
address. How these addresses are assigned to the logical entities is up to the network operator. For example, a 
single SIP URI may be assigned to all I-CSCFs, and the load shared between various physical boxes by 
underlying IP capabilities, or separate SIP URIs may be assigned to each I-CSCF, and the load shared between 
various physical boxes using DNS SRV capabilities. 

2) All IM CN subsystem entities are allocated IPv6 addresses in accordance with the constraints specified in 
3GPPTS 23.221 [6] subclause 5.1. 

3) The subscriber is allocated a private user identity by the home network operator, and this is contained within the 
ISIM application, if present, on the UICC. Where no ISIM application is present, the private user identity is 
derived from the IMSI, which is contained on the USIM (see 3GPP TS 23.003 [3]). This private user identity is 

available to the SIP application within the UE. 

NOTE: The SIP URIs may be resolved by using any of public DNSs, private DNSs, or peer-to-peer agreements. 

4) The subscriber is allocated one or more public user identities by the home network operator. At least one of these 
is contained within the ISIM application, if present, on the UICC. Where no ISIM application is present, the UE 
shall derive a temporary public user identity from the IMSI contained on the USIM (see 3GPP TS 23.003 [3]). 
All registered pubhc user identities are available to the SIP apphcation within the UE, after registration. 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



18 



ETSI TS 124 229 V5.11.1 (2005-01) 



5) For the purpose of access to the IM CN subsystem, UEs are assigned IPv6 prefixes in accordance with the 
constraints specified in 3GPP TS 23.221 [6] subclause 5.1 (see subclause 9.2.1 for the assignment procedures). 

4.2A Transport mechanisms 

This document makes no requirement on the transport protocol used to transfer signalling information over and above 
that specified in RFC 3261 [26] clause 18. However, the UE and IM CN subsystem entities shall transport SIP messages 
longer than 1300 bytes according to the procedures of RFC 3261 [26] subclause 18.1.1, even if a mechanism exists of 
discovering a maximum transmission unit size longer than 1500 bytes. 

4.3 Routeing principles of IIVI CN subsystem entities 

Each IM CN subsytem functional entity shall apply loose routeing policy as described in RFC 3261 [26], when 
processing a SIP request. In cases where the I-CSCF or the S-CSCFmay interact with strict routers in non IM CN 
subsystem networks, the routeing procedures defined in RFC 3261 [26] that ensure interoperability with strict routers 
shall be used by the I-CSCF and S-CSCF. 

4.4 Trust domain 

RFC 3325 [34] provides for the existence and trust of an asserted identity within a trust domain. For the IM CN 
subsystem, this trust domain consists of the P-CSCF, the 1-CSCF, the S-CSCF, the BGCF. the MGCF, the MRFC, and 
all ASs that are not provided by third-party service providers. ASs provided by third-party service providers are outside 
the trust domain. Except when communicating with the UE, functional entities within the trust domain can safely 
consider that there are no requirements to take an action on the removal of the P-Asserted-Identity header, unless 
otherwise explicitly stated. 

For the purpose of the P-Access-Network-Info header, a trust domain also applies. This trust domain is identical to that 
of the P-Asserted-Identity. For the P- Access-Network-Info header, subclause 5.4 also identifies additional cases for the 
removal of the header. 

NOTE: In addition to the procedures specified in clause 5, procedures of RFC 3325 [34] in relation to 

transmission of P-Asserted-Identity headers and their contents outside the trust domain also apply. 

4.5 Charging correlation principles for IIVI CN subsystems 
4.5.1 Overview 

This subclause describes charging correlation principles to aid with the readability of charging related procedures in 
clause 5. See 3GPP TS 32.200 [16] and 3GPP TS 32.225 [17] for further information on charging. The interface 
between the PDF and P-CSCF is not defined in this release. 

The IM CN subsystem generates and retrieves the following charging correlation information for later use with offline 
and online charging: 

1 . IM CN subsystem Charging Identifier (ICID); 

2. Access network charging information: 
a. GPRS Charging Information; 

3. Inter Operator Identifier (lOI); 

4. Charging function addresses: 

a. Charging Collection Function (CCF); 

b. Event Charging Function (ECF). 

How to use and where to generate the parameters in IM CN subsystems are described further in the subclauses that 
foUow. The charging correlation information is encoded in the P-Charging- Vector header as defined in 
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subclause 7.2A.5. The P-Charging- Vector header contains the following parameters: icid, access network charging 

information and ioi. 

The offline and onhne charging function addresses are encoded in the P-Charging-Function- Addresses as defined in 
RFC 3455 [52]. The P-Charging-Function- Addresses header contains the following parameters: CCF and ECF. 

4.5.2 IM CN subsystem charging identifier (ICID) 

The ICID is the session level data shared among the IM CN subsystem entities including ASs in both the calling and 
called IM CN subsystems. The ICID is used also for session unrelated messages (e.g. SUBSCRIBE request, NOTIFY 
request, MESSAGE request) for the correlation with CDRs generated among the IM CN subsystem entities. 

The first IM CN subsystem entity involved in a dialog (session) or standalone (non-session) method will generate the 
ICID and include it in the icid parameter of the P-Charging- Vector header in the SIP request. See 3GPP TS 32.225 [17] 
for requirements on the format of ICID. The P-CSCF will generate an ICID for mobile-originated calls. The I-CSCF 
will generate an ICID for mobile-terminated calls if there is no ICID received in the initial request (e.g. the calling party 
network does not behave as an IM CN subsystem). The AS will generate an ICID when acting as an originating UA. 
The MGCF will generate an ICID for PSTN/PLMN originated calls. Each entity that processes the SIP request will 
extract the ICID for possible later use in a CDR. The I-CSCF and S-CSCF are also allowed to generate a new ICID for 
mobile terminated calls received from another network. 

There is also an ICID generated by the P-CSCF with a REGISTER request that is passed in a unique instance of P- 
Charging- Vector header. The valid duration of the ICIDis specified in 3GPP TS 32.225 [17]. 

The icid parameter is included in any requests that include the P-Charging- Vector header. However, the P-Charging- 
Vector (and ICID) is not passed to the UE. 

The ICID is also passed from the P-CSCF/PDF to the GGSN, but the ICID is not passed to the SGSN. The interface 
supporting this operation is outside the scope of this document. 

4.5.3 Access network cliarging information 

4.5.3.1 General 

The access network charging information are the media flow level data shared among the IM CN subsystem entities for 
one side of the session (either the calling or called side). GPRS charging information (GGSN identifier and PDP context 
information) is an example of access network charging information. 

4.5.3.2 GPRS charging information 

The GGSN provides the GPRS charging information to the IM CN subsystem, which is the common information used 
to correlate GGSN CDRs with IM CN subsystem CDRs. The GPRS charging information is used to correlate the bearer 
level (i.e. PDP context) with session level. 

The GPRS charging information is generated at the first opportunity after the resources are allocated at the GGSN. The 
GPRS charging ingormation is passed from GGSN to P-CSCF/PDF. GPRS charging information will be updated with 
new information during the session as media flows are added or removed. The P-CSCF provides the GPRS charging 
information to the S-CSCF. The S-CSCF may also pass the information to an AS, which may be needed for online pre- 
pay applications. The GPRS charging information for the originating network is used only within that network, and 
similarly the GPRS charging information for the terminating network is used only within that network. Thus the GPRS 
charging information are not shared between the calling and called networks. The GPRS charging information is not 
passed towards the external ASs from its own network. 

The GPRS charging information is populated in the P-Charging- Vector using the gprs-charging-info parameter. The 
details of the gprs-charging-info parameter is described in subclause 7.2A.5. 

4.5.4 Inter operator identifier (101) 

The Inter Operator Identifier (IOI) is a globally unique identifier to share between operator networks/service 
providers/content providers. There are two possible instances of an IOI to be exchanged between networks/service 
providers/content providers: one for the originating side, orig-ioi, and one for the terminating side, term-ioi. 
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The S-CSCF in the originating network populates the orig-ioi parameter of the P-Charging- Vector header in the initial 
request, which identifies the operator network from which the request originated. Also in the initial request, the term-ioi 
parameter is left out of the P-Charging-Vector header. The S-CSCF in the originating network retrieves the term-ioi 
parameter from the P-Charging-Vector header within the message sent in response to the initial request, which identifies 
the operator network from which the response was sent. 

The S-CSCF in the terminating network retrieves the orig-ioi parameter from the P-Charging- Vector header in the 
initial request, which identifies the operator network from which the request originated. The S-CSCF in the terminating 
network populates the term-ioi parameter of the P-Charging- Vector header in the response to the initial request, which 
identifies the operator network from which the response was sent. 

The MGCF takes responsibiUty for populating the orig-ioi parameter when a call/session is originated from the 
PSTN/PLMN. The MGCF takes responsibility for populating the term-ioi parameter when a call/session is terminated at 
the PSTN/PLMN. 

lOIs will not be passed along within the network, except when proxied by BGCF and I-CSCF to get to MGCF and S- 
CSCF. However, lOIs will be sent to the AS for accounting purposes. 

4.5.5 Charging function addresses 

Charging function addresses are distributed to each of the IM CN subsystem entities in the home network for one side 
of the session (either the calling or called side) and are to provide a common location for each entity to send charging 
information. Charging Collection Function (CCF) addresses are used for offline billing. Event Charging Function (ECF) 
addresses are used for online billing. 

There may be multiple addresses for CCF and ECF addresses populated into the P-Charging-Function- Addresses header 
of the SIP request or response. The parameters are ccf and ecf. Only one instance of ccf is required. Additional ccf 

addresses may be included by each network for redundancy purposes, but the first instance of ccf is the primary address. 
If ecf address is included for online charging, then additional instances may also be included for redundancy. 

The CCF addresses and ECF addresses are retrieved from an Home Subscriber Server (HSS) via the Cx interface and 
passed by the S-CSCF to subsequent entities. The charging function addresses are passed from the S-CSCF to the IM 
CN subsystem entities in its home network, but are not passed to the visited network or the UE. When the P-CSCF is 
allocated in the visited network, then the charging function addresses are obtained by means outside the scope of this 
document. The AS receives the charging fimction addresses from the S-CSCF via the ISC interface. CCF and/or ECF 
addresses may be allocated as locally preconfigured addresses. The AS may also retrieve the charging fimction address 
from the HSS via Sh interface. 



5 Application usage of SIP 

5.1 Procedures at the UE 

5.1 .1 Registration and autlientication 

5.1.1.1 General 

The UE shall register public user identities (see table A.4/1 and dependencies on that major capability). 

In case a UE registers several public user identities at different points in time, the procedures to re-register, deregister 
and subscribe to the registration-state event package for these public user identities can remain imcoordinated in time. 

5. 1.1.1 A Parameters contained in the UiCC 

If there is an ISIM and a USIM application on a UICC, then the ISIM application shall always be used for IMS 
authentication, as described in 3GPP TS 33.203 [19]. 

In case the UE is loaded with a UICC that contains the ISIM application, it will be preconfigured with all the necessary 
parameters to initiate the registration to the IM CN subsystem. These parameters include: 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



21 



ETSI TS 124 229 V5.11.1 (2005-01) 



- the private user identity; 

- one ore more public user identities; and 

- the home network domain name used to address the SIP REGISTER request 

In case the UE is loaded with a UICC that does not contain the ISIM apphcation, the UE shall: 
generate a private user identity; 
generate a temporary public user identity; and 

- generate a home network domain name to address the SIP REGISTER request to. 

All these three parameters are derived from the IMSl parameter in the USIM, according to the procedures described in 
3GPP TS 23.003 [3]. If the UICC does not contain the ISlM application, the UE shall derive new values every time the 
UICC is changed, and shall discard existing values if the UICC is removed. 

The temporary public user identity is only used in REGISTER requests, i.e. initial registration, re-registration, mobile- 
initiated deregistration. After a successful registration, the UE will get the associated public user identities, and the UE 
may use any of them in subsequent non-REGlSTER requests. 

The UE shall not reveal to the user the temporary public user identity if the temporary public user identity is barred. The 
temporary public user identity is not barred if received by the UE in the P-Associated-URI header. 

5.1.1.2 Initial registration 

The UE can register a public user identity at any time that a valid PDP context exists. However, the UE shall only 
initiate a new registration procedure when it has received a final response from the registrar for the ongoing registration, 
or the previous REGISTER request has timed out. 

A REGISTER request may be protected using a security association, see 3GPP TS 33.203 [19], established as a result 
of an earUer registration. 

The UE shall extract or derive from the UICC a pubUc user identity, the private user identity, and the domain name to 
be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A. A public 

user identity may be input by the end user. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) the Authorization header, with the usemame field, set to the value of the private user identity; 

b) the From header set to the SIP URI that contains the public user identity to be registered; 

c) the To header set to the SIP URI that contains the public user identity to be registered; 

d) the Contact header set to include SIP URI(s) containing the IP address of the UE in the hostport parameter or 
FQDN. If the REGISTER request is protected by a security association, the UE shall also include the protected 
server port value in the hostport parameter; 

e) the Via header containing the IP address or FQDN of the UE in the sent-by field. If the REGISTER request is 
protected by a security association, the UE shall also include the protected server port value in the sent-by field. 

NOTE 1: If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
association. For details on the selection of the protected port value see 3GPP TS 33.203 1 19|. 

f) the Expires header, or the expires parameter within the Contact header, set to the value of 600 000 seconds as the 
value desired for the duration of the registration; 

NOTE 3: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network pohcy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



22 



ETSI TS 124 229 V5.11.1 (2005-01) 



g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) the Security-Client header field set to specify the security mechanism the UE supports, the IPsec layer 
algorithms the UE supports and the parameters needed for the security association setup. The UE shall support 
the setup of two pairs of security associations as defined in 3GPP TS 33.203 [19]. The syntax of the parameters 
needed for the security association setup is specified in Annex H of 3GPP TS 33.203 [19]. The UE shall support 
the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The UE shall support the HMAC-MD5-96 
(RFC 2403 [20C]) and HMAC-SHA-1-96 (RFC 2404 [20D]) IPsec layer algorithms, and shall announce support 
for them according to the procedures defined in RFC 3329 [48]; 

i) the Supported header containing the option tag "path"; and 

j) if a security association exists, a P-Access-Network-Info header that contains information concerning the access 
network technology and, if applicable, the cell ID (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 

a) store the expiration time of the registration for the pubUc user identities found in the To header value; 

b) store the list of URIs contained in the P-Associated-URI header value. This list contains the URIs that are 
associated to the registered public user identity; 

c) store as the default public user identity the first URI on the list of URIs present in the P-Associated-URI header; 

d) treat the identity imder registration as a barred pubUc user identity, if it is not included in the P-Associated-URI 
header; 

e) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 

preloaded Route header value for new dialogs; and 

f) set the security association hfetime to the longest of either the previously existing security association lifetime (if 
available), or the lifetime of the just completed registration plus 30 seconds. 

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in 
subclause 5.1.1.5.1. 

On receiving a 423 (Interval Too Brief) too brief response to the REGISTER request, the UE shall: 

- send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 



5.1 .1 .3 Initial subscription to the registration-state event pacl^age 

Upon receipt of a 2xx response to the initial registration, the UE shall subscribe to the reg event package for the public 
user identity registered at the users registrar (S-CSCF) as described in RFC 3680 [43]. 

The UE shall use the default public user identiy for subscription to the registration-state event package, if the public 
user identity that was used for initial registration is a barred public user identity. The UE may use either the default 
pubUc user identity or the public user identity used for initial registration for the subscription to the registration-state 
event package, if the initial public user identity that was used for initiaial registratioin is not barred. 

On sending a SUBSCRIBE request, the UE shall populate the header fields as follows: 

a) a Request URI set to the resource to which the UE wants to be subscribed to, i.e. to a SIP URI that contains the 
public user identity used for subscription; 

b) a From header set to a SIP URI that contains the public user identity used for subscription; 

c) a To header set to a SIP URI that contains the public user identity used for subscription; 

d) an Event header set to the "reg" event package; 

e) an Expires header set to 600 000 seconds as the value desired for the duration of the subscription; and 

f) a P- Access-Network-Info header that contains information concerning the access network technology and, if 
applicable, the cell ID (see subclause 7.2A.4). 
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Upon receipt of a 2xx response to the SUBSCRIBE request, the UE shall store the information for the established 
dialog and the expiration time as indicated in the Expires header of the received response. 

If continued subscription is required the UE shall automatically refresh the subscription by the reg event package, for a 
previously registered public user identity, either 600 seconds before the expiration time if the initial subscription was 
for greater than 1200 seconds, or when half of the time has expired if the initial subscription was for 1200 seconds or 
less. 

5.1.1.4 User-initiated re-registration 

The UE can reregister a previously registered public user identity at any time. 

Unless either the user or the application within the UE has determined that a continued registration is not required the 
UE shall reregister the public user identity either 600 seconds before the expiration time if the initial registration was for 
greater than 1200 seconds, or when half of the time has expired if the initial registration was for 1200 seconds or less. 

The UE shall protect the REGISTER request using a security association, see 3GPP TS 33.203 [19], established as a 

result of an earlier registration, if IK is available. 

The UE shall extract or derive from the UICC a pubUc user identity, the private user identity, and the domain name to 
be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A. 

On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as 
follows: 

a) an Authorization header, with the usemame field set to the value of the private user identity; 

b) a From header set to the SIP URI that contains the public user identity to be registered; 

c) a To header set to the SIP URI that contains the public user identity to be registered; 

d) a Contact header set to include SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or 
FQDN and protected server port value boimd to the security association; 

e) a Via header containing the IP address or FQDN of the UE in the sent-by field and the protected server port value 
bound to the security association; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 

Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

NOTE 2: The UE associates two ports, a protected client port and a protected server port, with each pair of security 
associations. For details on the selection of the protected port value see 3GPP TS 33.203 [19]. 

f) an Expires header, or an expires parameter within the Contact header, set to 600 000 seconds as the value desired 
for the duration of the registration; 

NOTE 3: The registrar (S-CSCF) might decrease the duration of the registration in accordance with network poUcy. 
Registration attempts with a registration period of less than a predefined minimum value defined in the 
registrar will be rejected with a 423 (Interval Too Brief) response. 

g) a Request-URI set to the SIP URI of the domain name of the home network; 

h) a Security-CUent header field, set to specify the security mechanism it supports, the IPsec layer algorithms it 
supports and the new parameter values needed for the setup of two new pairs of security associations. For 
fiirther details see 3GPP TS 33.203 [19] and RFC 3329 [48]; 

i) a Security- Verify header that contains the content of the Security-Server header received in the 401 
(Unauthorized) response of the last successful authentication; 

j) the Supported header containing the option tag "path"; and 

k) the P-Access-Network-Info header that contains information concerning the access network technology and, if 
applicable, the cell ID (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall: 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



24 



ETSI TS 124 229 V5.11.1 (2005-01) 



a) store the new expiration time of the registration for this public user identity found in the To header value; 

b) store the list of URIs contained in the P-Associated-URI header value. This list contains the URIs that are 
associated to the registered public user identity; 

c) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper 
preloaded Route header value for new dialogs; and 

d) set the security association lifetime to the longest of either the previously existing security association lifetime, 
or the lifetime of the just completed registration plus 30 seconds. 

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in 
subclause 5.1.1.5.1. 

On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall: 

- send another REGISTER request populating the Expires header or the expires parameter with an expiration timer 
of at least the value received in the Min-Expires header of the 423 (Interval Too Brief) response. 



Authentication is achieved via the registration and re-registration procedures. When the network requires authentication 
or re-authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request. 

On receiving a 401 (Unauthorized) response to the REGISTER request, the UE shall: 

1) extract the RAND and AUTN parameters; 

2) check the vaUdity of a received authentication challenge, as described in 3GPP TS 33.203 [19] i.e. the locally 

calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN 
parameter derived from the AUTN part of the challenge must be within the correct range; and 

3) check the existence of the Security-Server header as described in RFC 3329 [48]. If the header is not present or it 
does not contain the parameters required for the setup of the set of security associations (see annex H of 

3GPP TS 33.203 [19]), the UE shall abandon the authentication procedure and send a new REGISTER request 
with a new Call-ID. 

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall: 

1) calculate the RES parameter and derive the keys CK and IK from RAND as described in 3GPP TS 33.203 [19]; 

2) set up a temporary set of security associations based on the static list and parameters it received in the 401 
(Unauthorized) response and its capabilities sent in the Security-Chent header in the REGISTER request. The 
UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned 
by the P-CSCF and supported by the UE and using IK as the shared key. The UE shall use the parameters 
received in the Secmity- Server header to setup the temporary set of security associations. The UE shall set a 
temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer; 
and 

3) send another REGISTER request using the temporary set of security associations to protect the message. The 
header fields are populated as defined for the initial request, with the addition that the UE shall include an 
Authorization header containing the private user identity and the authentication challenge response calculated by 
the UE using RES and other parameters, as described in RFC 3310 [49]. The UE shall also insert the Security- 
Client header that is identical to the Security-Client header that was included in the previous REGISTER request 
(i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall 
also insert the Security- Verify header into the request, by mirroring in it the content of the Security-Server 
header received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the integrity protected 
REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 
401 (Unauthorized) response which carried the challenge. 

On receiving the 200 (OK) response for the integrity protected REGISTER request, the UE shall: 
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change the temporary set of security associations to a newly established set of security associations, i.e. set its 
SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or 
the lifetime of the just completed registration plus 30 seconds; and 

- use the newly estabUshed set of security associations for further messages sent towards the P-CSCF as 
appropriate. 

NOTE: In this case, the UE will send requests towards the P-CSCF over the newly established set of security 
associations. Responses towards the P-CSCF that are sent via UDP will be sent over the newly 
established set of security associations. Responses towards the P-CSCF that are sent via TCP wiU be sent 
over the same set of security associations that the related request was received on. 

When the first request or response protected with the newly established set of security associations is received from the 
P-CSCF, the UE shall delete the old set of security associations and related keys it may have with the P-CSCF after all 
SIP transactions that use the old set of security associations are completed. 

Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security 
associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The 
UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security 
associations. The UE should send an unprotected REGISTER message according to the procedure specified in 
subclause 5.1.1.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF. 

In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in 
subclause 5.1.1.5.3. 

5.1.1.5.2 Network-initiated re-autlientication 

At any time, the UE can receive a NOTIFY request carrying information related to the reg event package (as described 
in subclause 5.1.1.3). If: 

- the state attribute in any of the <registration> elements is set to "active"; 

- the value of the <uri> sub-element inside the <contact> sub-element is set to the Contact address that the UE 
registered; and 

- the event attribute of that <contact> sub-element(s) is set to "shortened"; 
the UE shall: 

1) use the expiry attribute within the <contact> element to adjust the expiration time for that public user identity; 
and 

2) start the re-authentication procedures at the appropriate time (as a result of the S-CSCF procedure described in 
subclause 5.4.1.6) by initiating a reregistration as described in subclause 5.1.1.4. 

5.1.1.5.3 Abnormal cases 

If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further 
REGISTER indicating to the S-CSCF that the challenge has been deemed invaUd as follows: 

- in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall 
contain no authentication challenge response and no AUTS parameter; 

- in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the 
AUTS parameter and not an authentication challenge response (see 3GPP TS 33.102 [18]). 

Whenever the UE detects any of the above cases, the UE shall: 

- send the REGISTER request using an existing set of security associations, if available (see 
3GPPTS 33.203 [19]); 

a new Security-Client header within the REGISTER request, set to specify the security mechanism it supports, the 
IPsec layer algorithms it supports and the parameters needed for the new security association setup; and 

- not create a temporary set of security associations. 
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A UE shall only respond to two consecutive invalid challenges. The UE may attempt to register with the network again 
after an implementation specific time. 

5.1 .1 .5A Change of IP address due to privacy 

Stateless address autoconfiguration as described in RFC 2462 [20E] defines how an IPv6 prefix and an interface 
identifier is used by the UE to construct a complete IPv6 address. 

If the UE receives an IPv6 prefix, the UE may change the interface identity of the IPv6 address as described in 
RFC 3041 [25A] due to privacy but this will result in service discontinuity for IMS services. 

NOTE: The procedure described below will terminate all established dialogs and transactions and temporarily 

disconnect the UE from the IM CN subsystem until the new registration is performed. Due to this, the UE 
is recommended to provide a Umited use of the procedure to ensure a maximum degree of continuous 
service to the end user. 

In order to change the IPv6 address due to privacy, the UE shall: 

1) terminate all ongoing dialogs (e.g., sessions) and transactions (e.g., subscription to the reg event); 

2) deregister all registered pubUc user identities as described in subsclause 5 . 1 . 1 .4; 

3) construct a new IPv6 address according to the procedures specified in RFC 3041 [25A]; 

4) register the public user identities that were deregistered in step 2 above, as follows: 

a) by performing an initial registration as described in subsclause 5.1.1.2; and 

b) by performing a subscription to the reg event package as described in subsclause 5.1.1.3; and 

5) subscribe to other event packages it was subscribed to before the change of IP address procedure started. 

5.1.1.6 User-initiated deregistration 

The UE can deregister a previously registered public user identity at any time. 

The UE shall integrity protect the REGISTER request using a security association, see 3GPP TS 33.203 [19], 
estabUshed as a result of an earlier registration, if one is available. 

The UE shall extract or derive from the UICC a public user identity, the private user identity, and the domain name to 
be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A. 

Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs related to the public user 
identity that is going to be deregistered or to one of the implicitly registered public user identities. 

On sending a REGISTER request, the UE shall populate the header fields as follows: 

a) the Authorization header, with the usemame field, set to the value of the private user identity; 

b) the From header set to the SIP URI that contains the public user identity to be deregistered; 

c) the To header set to the SIP URI that contains the public user identity to be deregistered; 

d) the Contact header set to either the value of "*" or SIP URI(s) that contain(s) in the hostport parameter the IP 
address of the UE or FQDN and the protected server port value bound to the security association; 

e) a Via header containing the IP address or FQDN of the UE in the sent-by field and the protected server port value 
bound to the security association; 

NOTE 1 : If the UE specifies its FQDN in the host parameter in the Contact header and in the sent-by field in the 
Via header, then it has to ensure that the given FQDN will resolve (e.g., by reverse DNS lookup) to the IP 
address that is bound to the security association. 

f) the Expires header, or the expires parameter of the Contact header, set to the value of zero, appropriate to the 
deregistration requirements of the user; 
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g) a Request-URI set to the SIP URI of the domain name of the home network; and 

h) a P- Access-Network-Info header that contains information concerning the access network technology and, if 
appHcable, the cell ID (see subclause 7.2A.4). 

On receiving the 200 (OK) response to the REGISTER request, the UE shall remove all registration details relating to 
this public user identity. 

If there are no more public user identities registered, the UE shall delete the security associations and related keys it 
may have towards the P-CSCF. 

If all public user identities are deregistered and the security association is removed, then the UE shall consider 
subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires 
header containing a value of zero). 

NOTE: When the UE has received the 200 (OK) response for the REGISTER request of the only public user 
identity currently registered with its associated set of implicitly registered public user identities (i.e. no 
other is registered), the UE removes the security association established between the P-CSCF and the UE. 
Therefore further SIP signalling (e.g. the NOTIFY request containing the deregistration event) will not 
reach the UE. 

5.1.1.7 Network-initiated deregistration 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as 
described in subclause 5.1.1.3, including one or more <registration> element(s) with the state attribute set to 
"terminated" and the event attribute set to "rejected" or "deactivated", the UE shall remove all registration details 
relating to these public user identities. In case of a "deactivated" event attribute, the UE shall start the initial registration 
procedure as described in subclause 5.1.1.2. In case of a "rejected" event attribute, the UE shall release all dialogs 
related to those pubUc user identities. 

Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. 
all public user identities are deregistered) and the Subscription-State header contains the value of "terminated", the UE 
shall delete the security associations towards the P-CSCF after the server transaction (as defined in RFC 3261 [26]) 
pertaining to the NOTIFY request terminates. 

NOTE 1 : Deleting a security association is an internal procedure of the UE and does not involve any SIP 
procedures. 

NOTE 2: If the security association towards the P-CSCF is removed, then the UE considers the subscription to the 

reg event package terminated (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header 
containing a value of zero, or a NOTIFY request was received with Subscription-State header containing 
the value of "terminated"). 

NOTE 3: When the P-CSCF has removed the security association established between the P-CSCF and the UE, 
further SIP signalling (e.g. the NOTIFY containing the deregistration event) will not reach the UE. 

5.1 .2 Subscription and notification 

5.1 .2.1 Notification about multiple registered public user identities 

Upon receipt of a 2xx response to the SUBSCRIBE request the UE shall maintain the generated dialog (identified by 
the values of the Call-ID, To and From headers). 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package the 
UE shall perform the following actions: 

if a state attribute "active", i.e. registered is received for one or more pubUc user identities, the UE shall store the 
indicated public user identities as registered; 

- if a state attribute "terminated", i.e. deregistered is received for one or more pubhc user identities, the UE shall 
store the indicated pubhc user identities as deregistered. 
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NOTE: There may be public user identities which are automatically registered within the registrar (S-CSCF) of 



the user upon registration of one public user identity. Usually these automatically or implicitly registered 
public user identities belong to the same service profile of the user and they might not be available within 
the UE. The implicitly registered pubhc user identities may also belong to different service profiles. The 
here-described procedures provide a different mechanism (to the 200 (OK) response to the REGISTER 
request) to inform the UE about these automatically registered public user identities. 



If the UA receives a 503 (Service Unavailable) response to an initial SUBSCRIBE request containing a Retry-After 
header, then the UE shall not automatically reattempt the request until after the period indicated by the Retry- After 
header contents. 



5.1 .2A Generic procedures applicable to all methods excluding the 
REGISTER method 

5.1 .2A. 1 Mobile-originating case 



The procedures of this subclause are general to all requests and responses, except those for the REGISTER method. 
When the UE sends any request, the UE shall: 

- include the protected server port in the Via header entry relating to the UE; and 

- include the protected server port in any Contact header that is otherwise included. 

The UE shall discard any SIP response that is not integrity protected and is received from the P-CSCF outside of the 
registration and authentication procedures. The requirements on the UE within the registration and authentication 
procedures are defined in subclause 5.1.1. 

In accordance with RFC 3325 [34] the UE may insert a P-Preferred-Identity header in any initial request for a dialog or 
request for a standalone transaction as a hint for creation of an asserted identity within the IM CN subsystem. The UE 
may include any of the following in the P-Preferred-Identity header: 

- a public user identity which has been registered by the user; 

a public user identity returned in a registration-state event package of a NOTIFY request as a result of an implict 
registration that was not subsequently deregistered or has expired; or 

- any other public user identity which the user has assumed by mechanisms outside the scope of this specification 
to have a current registration. 

NOTE 1: The temporary public user identity specified in subclause 5.1.1.1 is not a public user identity suitable for 
use in the P-Preferred-Identity header. 

NOTE 2: Procedures in the network require international public teleconmiunication numbers when telephone 
numbers are used in P-Preferred-Identity header. 

Where privacy is required, in any initial request for a dialog or request for a standalone transaction, the UE shall set the 
From header to "Anonymous". 

NOTE 3: The contents of the From header should not be relied upon to be modified by the network based on any 



privacy specified by the user either within the UE indication of privacy or by network subscription or 
network policy. Therefore the user should include the value "Anonymous" whenever privacy is expUcitly 
required. As the user may well have privacy requirements, terminal manufacturers should not 
automatically derive and include values in this header from the public user identity or other values stored 
in or derived from the UICC. Where the user has not expressed a preference in the configuration of the 
terminal implementation, the implementation should assume that privacy is required. Users that require to 
identify themselves, and are making calls to SIP destinations beyond the IM CN subsystem, where the 
destination does not implement RFC 3325 [34], will need to include a value in the From header other than 
Anonymous. 



5.1.2.2 



General SUBSCRIBE requirements 
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The UE can indicate privacy of the P-Asserted-Identity that will be generated by the P-CSCF in accordance with 
RFC 3323 [33], and the additional requirements contained within RFC 3325 [34]. 

The UE shall insert a P-Access-Network-Info header into any request for a dialog, any subsequent request (except ACK 
requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any request for a 
standalone method. This header shall contain information concerning the access network technology and, if applicable, 
the cell ID (see subclause 7.2A.4). 

The UE shall build a proper preloaded Route header value for all new dialogs and standalone transactions. The UE shall 
build a list of Route header values made out of, in this order, the P-CSCF URI (containing the IP address or the FQDN 
learnt through the P-CSCF discovery procedures, and the protected port learnt during the registration procedure), and 
the values received in the Service-Route header saved from the 200 (OK) response to the last registration or re- 
registration. 

5.1.2A.2 Mobile-terminating case 

The procedures of this subclause are general to all requests and responses, except those for the REGISTER method. 
When the UE sends any response, the UE shall: 

- include the protected server port in any Contact header that is otherwise included. 

The UE shall discard any SIP request that is not integrity protected and is received from the P-CSCF outside of the 
registration and authentication procedures. The requirements on the UE within the registration and authentication 
procedures are defined in subclause 5.1.1. 

The UE can indicate privacy of the P-Asserted-ldentity that will be generated by the P-CSCF in accordance with 
RFC 3323 |33|, and the additional requirements contained within RFC 3325 [34]. 

NOTE 1 ; In the mobile-terminating case, this version of the document makes no provision for the UE to provide an 
P-Preferred-Identity in the form of a hint. 

The UE shall insert a P-Access-Network-Info header into any response to a request for a dialog, any subsequent request 
(except CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone 
method. This header shall contain information concerning the access network technology and, if applicable, the cell ID 
(see subclause 7.2A.4). 

5.1 .3 Call initiation - mobile originating case 
5.1.3.1 Initial INVITE 

Upon generating an initial INVITE request, the UE shall: 

- indicate the support for reUable provisional responses and specify it using the Supported header mechanism; 

- indicate the requirement of precondition and specify it using the Require header mechanism. 

NOTE: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 . While proxies in 

the IM CN subsystem do not fork requests, proxies external to the system may initiate forking, such that 
the UE is able to receive several forked provisional or fmal responses from different terminations. The 
UE may accept or reject any of the forked responses, for example, if the UE is capable of supporting a 
Umited number of simultaneous transactions or early dialogs. 

When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The UE shall 
not progress any further early dialogues to established dialogs. Therefore, upon the reception of a subsequent final 200 
(OK) response for an INVITE request (e.g., due to forking), the UE shall: 

1) acknowledge the response with an ACK request; and 

2) send a BYE request to this dialog in order to terminate it. 

If the UA receives a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After header, 
then the UE shall not automatically reattempt the request until after the period indicated by the Retry- After header 
contents. 
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If the UE receives a 488 (Not Acceptable Here) response to an initial INVITE request, the UE should send a new 
INVITE request containing SDP according to the procedures defined in subclause 6.1. 

If the UE receives a 420 (Bad Extension) response to an initial INVITE request with "precondition" option-tag in the 
Unsupported header field, the UE shall abort the session attempt and shall not resend this INVITE request without 
"precondition" option-tag in the Require header. 

NOTE: An example of where a new request would not be built is where knowledge exists within the UE, or 

interaction occurs with the user, such that it is known that the resultant SDP would describe a session that 
did not meet the user requirements. 

5.1 .4 Call initiation - mobile terminating case 
5.1.4.1 Initial INVITE 

Upon receiving an initial INVITE request without containing either Supported: precondition or Require: precondition 
header values, the UE shall generate a 421 (Extension Required) response indicating the required extension in the 
Require header field. 

Upon generating the first response to the initial INVITE request, the UE shall indicate the requirement for reliable 

provisional responses and specify it using the Require header mechanism.The UE shall send the 200 (OK) response to 
the initial INVITE request only after the local resource reservation has been completed. 

NOTE: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261. While proxy 
support of forking is precluded in the IM CN subsystem, proxies external to the system may initiate 
forking, such that the UE is able to receive several forked requests for the same transaction. 

5.1.5 Call release 

Void. 

5.1 .6 Emergency service 

A UE shall not attempt to establish an emergency session via the IM CN Subsystem when the UE can detect that the 
number dialled is an emergency number. The UE shall use the CS domain as described in 3GPP TS 24.008 [8]. 

In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing a XML 
body that includes an <altemative service> element with the <type> child element set to "emergency", the UE shall 
automatically: 

- send an ACK request to the P-CSCF as per normal SIP procedures; 

- attempt an emergency call setup according to the procedures described in 3GPP TS 24.008 [8]. 

The UE may also provide an indication to the user based on the text string contained in the <reason> element. 
As a consequence of this, a UE operating in MS operation mode C cannot perform emergency calls. 

5.1.7 Void 

5.2 Procedures at the P-CSCF 
5.2.1 General 

The P-CSCF shall support the Path and Service-Route headers. 

NOTE 1 : The Path header is only applicable to the REGISTER request and its 200 (OK) response. The Service- 
Route header is only appUcable to the 200 (OK) response of REGISTER request. 

When the P-CSCF sends any request or response to the UE, before sending the message the P-CSCF shall: 
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- remove the P-Charging-Function- Addresses and P-Charging- Vector headers, if present. 

When the P-CSCF receives any request or response from the UE, the P-CSCF shall: 

remove the P-Charging-Function- Addresses and P-Charging- Vector headers, if present. Also, the P-CSCF shall 
ignore any data received in the P-Charging-Function-Addresses and P-Charging- Vector headers; and 

may insert previously saved values into the P-Charging-Function-Addresses and P-Charging- Vector headers 
before forwarding the message. 

NOTE 2: When the P-CSCF is located in the visited network, then it will not receive the P-Charging-Function- 
Addresses header from the S-CSCF or I-CSCF. Instead, the P-CSCF discovers charging function 
addresses by other means not specified in this document. 

When the P-CSCF receives any request or response containing the P-Media- Authorization header from the S-CSCF, the 
P-CSCF shall remove the header. 

NOTE 3: If service based local policy applies, the P-CSCF will insert the P-Media- Authorization header as 
described in subclauses 5.2.7.2 and 5.2.7.3. 

NOTE 4: The P-CSCF will integrity protect all SIP messages sent to the UE outside of the registration and 

authentication procedures. The P-CSCF will discard any SIP message that is not integirity protected and 
is received outside of the registration and authentication procedures. The integrity protection and 
checking requirements on the P-CSCF within the registration and authentication procedures are defined in 
subclause 5.2.2. 



5.2.2 Registration 

When the P-CSCF receives a REGISTER request from the UE, the P-CSCF shall: 

1) insert a Path header in the request including an entry containing: 

- the SIP URI identifying the P-CSCF; 

an indication that requests routed in this direction of the path (i.e. from the S-CSCF to the P-CSCF) are 
expected to be treated as for the mobile-terminating case. This indication may e.g. be in a parameter in the 
URI, a character string in the user part of the URI, or be a port number in the URI; 

2) insert a Require header containing the option tag "path" ; 

3) insert a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]; 

4) insert the parameter "integrity-protected" (described in subclause 7.2A.2) with a value "yes" into the 
Authorization header field in case the REGISTER request was either received integrity protected with the 
security association created during an ongoing authentication procedure and includes an authentication challenge 
response (i.e. RES parameter), or it was received on the security association created during the last successful 
authentication procedure and with no authentication challenge response (i.e. no RES parameter), otherwise insert 
the parameter with the value "no"; 

5) in case the REGISTER request was received without integrity protection, then check the existence of the 
Security-Client header. If the header is present, then remove and store it. The P-CSCF shall remove the 'sec- 
agree' item from the Require header, and the header itself if this is the only entry. If the header is not present, 
then the P-CSCF shall return a suitable 4xx response; 

6) in case the REGISTER request was received integrity protected, then the P-CSCF shall: 

a) check the security association which protected the request. If the security association is a temporary one, then 
the request is expected to contain a Security-Verify header in addition to a Security-Client header. If there are 
no such headers, then the P-CSCF shall return a suitable 4xx response. If there are such headers, then the P- 
CSCF shall compare the content of the Security- Verify header with the content of the Security-Server header 
sent earher and the content of the Security-Chent header with the content of the Security-Chent header 
received in the challenged REGISTER. If those do not match, then there is a potential man-in-the-middle 
attack. The request should be rejected by sending a suitable 4xx response. If the contents match, the P-CSCF 
shall remove the Security- Verify and the Security-Client header, and the "sec-agree" item from the Require 
header, and the header itself if this is the only entry; 
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b) if the security association the REGISTER request was received on, is an aheady established one, then: 

the P-CSCF shall remove the Security- Verify header if it is present, and the "sec-agree" item from the 
Require header, and the header itself if this is the only entry; 

- a Security-Client header containing new parameter values is expected. If this header or any required 
parameter is missing, then the P-CSCF shall return a suitable 4xx response; 

- the P-CSCF shall remove and store the Security-Client header before forwarding the request to the S- 
CSCF; and 

c) check if the private user identity conveyed in the Authorization header of the integrity-protected REGISTER 
request is the same as the private user identity which was previously challenged or authenticated. If the 
private user identities are different, the P-CSCF shall reject the REGISTER request by returning a 403 
(Forbidden) response; 

7) insert a P-Visited-Network-ID header field, with the value of a pre-provisioned string that identifies the visited 
network at the home network; and 

8) determine the I-CSCF of the home network and forward the request to that I-CSCF. 

When the P-CSCF receives a 401 (Unauthorized) response to a REGISTER request, the P-CSCF shall: 

1) delete any temporary set of security associations established towards the UE; 

2) remove the CK and IK values contained in the 401 (Unauthorized) response and bind them to the proper private 
user identity and to the temporary set of security associations which wiU be setup as a result of this challenge. 
The P-CSCF shall forward the 401 (Unauthorized) response to the UE if and only if the CK and IK have been 

removed; 

3) insert a Security-Server header in the response, containing the P-CSCF static security list and the parameters 
needed for the security association setup, as specified in Annex H of 3GPP TS 33.203 [19]. The P-CSCF shall 

support the "ipsec-3gpp" security mechanism, as specified in RFC 3329 [48]. The P-CSCF shall support the 
HMAC-MD5-96 (RFC 2403 [20C]) and HMAC-SHA-1-96 (RFC 2404 L20DJ) IPsec layer algorithms; 

4) set up the temporary set of security associations with a temporary SIP level hfetime between the UE and the P- 
CSCF for the user identified with the private user identity. For further details see 3GPP TS 33.203 [19] and 
RFC 3329 [48]. The P-CSCF shall set the temporary SIP level lifetime for the temporary set of security 
associations to the value of reg-await-auth timer; and 

5) send the 401 (Unauthorized) response to the UE using the security association with which the associated 
REGISTER request was protected, or unprotected in case the REGISTER request was received unprotected. 

NOTE 1: The challenge in the 401 (Unauthorized) response sent back by the S-CSCF to the UE as a response to the 
REGISTER request is piggybacked by the P-CSCF to insert the Security-Server header field in it. The S- 
CSCF authenticates the UE, while the P-CSCF negotiates and sets up two pairs of security associations 
with the UE during the same registration procedure. For further details see 3GPP TS 33.203 [19]. 

When the P-CSCF receives a 200 (OK) response to a REGISTER request, the P-CSCF shall check the value of the 
Expires header field and/or Expires parameter in the Contact header. When the value of the Expires header field and/or 
expires parameter in the Contact header is different than zero, then the P-CSCF shall: 

1) save the list of Service-Route headers preserving the order. The P-CSCF shall store this list during the entire 
registration period of the respective public user identity. The P-CSCF shall use this list to vahdate the routeing 
information in the requests originated by the UE. If this registration is a reregistration, the P-CSCF shall replace 
the already existing list of Service-Route headers with the new list; 

2) associate the Service-Route header list with the registered pubUc user identity; 

3) store the public user identities found in the P-Associated-URI header value, as those that are authorized to be 
used by the UE; 

4) store the default public user identity for use with procedures for the P-Asserted-ldentity header. The default 
public user identity is the first on the list of URls present in the P-Associated-URI header; 
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NOTE 2: There may be more then one defauh public user identities stored in the P-CSCF, as the result of the 
multiple registrations of public user identities. 

5) store the values received in the P-Charging-Function- Addresses header; 

6) if a set of temporary security associations exists, change the temporary set of security associations to a newly 
established set of security associations, i.e. set its SIP level hfetime to the longest of either the previously 
existing set of security associations SIP level lifetime, or the Ufetime of the just completed registration plus 30 
seconds; and 

7) protect the 200 (OK) response to the REGISTER request within the same security association to that in which 

the request was protected. 

When receiving a SIP message (including REGISTER requests) from the UE over the newly estabhshed set of security 
associations that have not yet been taken into use, the P-CSCF shall: 

1) reduce the SIP level lifetime lifetime of the old set of security associations towards the same UE to 64*T1 (if 
currentiy longer than 64*T1); and 

2) use the newly estabhshed set of security associations for further messages sent towards the UE as appropriate 
(i.e. take the newly estabhshed set of security associations into use). 

NOTE 3: In this case, the P-CSCF will send requests towards the UE over the newly established set of security 

associations. Responses towards the UE that are sent via UDP will be sent over the newly estabhshed set 
of security associations. Responses towards the UE that are sent via TCP will be sent over the same set of 
security associations that the related request was received on. 

NOTE 4: When receiving a SIP message (including REGISTER requests) from the UE over a set of security 

associations that is different from the newly estabhshed set of security associations, the P-CSCF will not 
take any action on any set of security associations. 

When the SIP level lifetime of an old set of security associations is about to expire, i.e. their SIP level lifetime is shorter 
than 64*T1 and a newly established set of security associations has not been taken into use, the P-CSCF shall use the 
newly established set of security associations for further messages towards the UE as appropriate (see NOTE 3). 

When sending the 200 (OK) response for a REGISTER request that concludes a re-authentication, the P-CSCF shall: 

1) keep the set of security associations that was used for the REGISTER request that initiated the re-authentication; 

2) keep the newly estabhshed set of security associations created during this authentication; 

3) delete, if existing, any other set of security associations towards this UE immediately; and, 

4) go on using for further requests sent towards the UE the set of security associations that was used to protect the 
REGISTER request that initiated the re-authentication. 

When sending the 200 (OK) respone for a REGISTER request that concludes an initial authentication, i.e. the initial 
REGISTER request was received unprotected, the P-CSCF shall: 

1) keep the newly estabhshed set of security associations created during this authentication; 

2) delete, if existing, any other set of security associations towards this UE innmediately; and, 

3) use the kept newly estabhshed set of security associations for further messages sent towards the UE. 

NOTE 5: The P-CSCF will maintain two Route header lists. The first Route header list - created during the 
registration procedure - is used only to validate the routeing information in the initial requests that 
originate from the UE. This hst is valid during the entire registration of the respective pubhc user identity. 
The second Route hst - constructed from the Record Route headers in the initial INVITE and associated 
response - is used during the duration of the call. Once the call is terminated, the second Route list is 
discarded. 

The P-CSCF shall delete any security association from the IPsec database when their SIP level hfetime expires. 
The handling of the security associations at the P-CSCF is summarized in table 5.2.2-1. 
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Table 5.2.2-1 : Handling of security associations at the P-CSCF 





Temporary set of security 
associations 


Newly established set of 
security associations 


Old set of security 
associations 


SIP message received over 
newly established set of 
security associations that 
have not yet been taken into 

use 


No action 


Take into use 


Reduce SIP level lifetime to 
64*T1 , if lifetime is larger 
than 64*T1 


SIP message received over 
old set of security 
associations 


No action 


No action 


No action 


Old set of security 
associations currently in use 

will expire in 64*T1 


No action 


Take into use 


No action 


Sending an authorization 
challenge within a 401 
(Unauthorized) response for 
a REGISTER request 


Create 

Remove any previously 

existing temporary set of 
security associations 


No action 


No action 


Sending 200 (OK) response 
for REGISTER request that 
concludes re-authentlcation 


Change to a newly 
established set of security 
associations 


Convert to and treat as old 

set of security associations 
(see next column) 


Continue using the old set 
of security associations over 
which the REGISTER 
request, that initiated the re- 
authentication was received. 
Delete all other old sets of 
security associations 
immediately 


Sending 200 (OK) response 
for REGISTER request that 
concludes initial 
authentication 


Change to a newly 
established set of security 
associations and take into 
use immediately 


Convert to old set of 
security associations, i.e. 
delete 


Delete 



5.2.3 Subscription to tine user's registration-state event package 

Upon receipt of a 200 (OK) response to the initial REGISTER request of an user, the P-CSCF shall subscribe to the reg 
event package at the users registrar (S-CSCF) as described in RFC 3680 [43]. The P-CSCF shall: 

1) generate a SUBSCRIBE request with the following elements: 

- a Request-URI set to the resource to which the P-CSCF wants to be subscribed to, i.e. to a SIP URI that 
contains the default pubUc user identity of the user; 

- a From header set to the P-CSCF's SIP URI; 

- a To header, set to a SIP URI that contains the default public user identity of the user; 

- an Event header set to the "reg" event package; 

- an Expires header set to a value higher then the Expires header indicated in the 200 (OK) response to the 
REGISTER request; 

- a P-Asserted-Identity header set to the SIP URI of the P-CSCF, which was inserted into the Path header 
during the registration of the user to whose registration state the P-CSCF subscribes to; and 

a P-Charging-Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]; and 

2) determine the 1-CSCF of the home network (e.g., by using DNS services); 

before sending the SUBSCRIBE request to that I-CSCF, according to the procedures of RFC 3261 [26]. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the P-CSCF shall store the information for the so 
established dialog and the expiration time as indicated in the Expires header of the received response. 

If continued subscription is required the P-CSCF shall automatically refresh the subscription by the reg event package 
600 seconds before the expiration time for a previously registered pubUc user identity, either 600 seconds before the 
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expiration time if the initial subscription was for greater than 1200 seconds, or when half of the time has expired if the 
initial subscription was for 1200 seconds or less. 

5.2.4 Registration of multiple public user identities 

Upon receipt of a 2xx response to the SUBSCRIBE request the P-CSCF shall maintain the generated dialog (identified 
by the values of the Call-ID, To and From headers). 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package, the 
P-CSCF shall perform the following actions: 

if a state attribute "active", i.e. registered, is received for one or more public user identities, the P-CSCF shall 
bind the indicated public user identities as registered to the contact information of the user; 

- if a state attribute "terminated", i.e. deregistered, is received for one or more public user identities, the P-CSCF 
shall release all stored information for these public user identities. 

NOTE: There may be public user identities which are implicitly registered within the registrar (S-CSCF) of the 
user upon registration of one public user identity. The procedures in this subclause provide a mechanism 
to inform the P-CSCF about these implicitly registered pubUc user identities. 

5.2.5 Deregistration 

5.2.5.1 User-initiated deregistration 

When the P-CSCF receives a 200 (OK) response to a REGISTER request (sent according to subclause 5.2.2), it shall 
check the value of the Expires header field and/or expires parameter in the Contact header field. When the value of the 
Expires header field or expires parameter equals zero, then the P-CSCF shall: 

1) remove the pubhc user identity found in the To header field, and all the associated public user identities, from 
the registered public user identities list and all related stored information; and 

2) check if the user has left any other registered public user identity. When all of the public user identities of a user 
are deregistered, the P-CSCF shall delete the security associations towards that user after the server transaction 
(as defined in RFC 3261 [26]) pertaining to this deregistration terminates. 

NOTE 1: Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to 
"terminated" (i.e. all public user identities are deregistered) and the Subscription-State header set to 
"terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the P- 
CSCF had sent a SUBSCRIBE request with an Expires header containing a value of zero). 

NOTE 2: There is no requirement to distinguish a REGISTER request relating to a registration from that relating to 
a deregistration. For administration reasons the P-CSCF may distinguish such requests, however this has 
no impact on the SIP procedures. 

NOTE 3: When the P-CSCF has sent the 200 (OK) response for the REGISTER request of the only pubUc user 
identity currently registered with its associated set of implicitly registered public user identities (i.e. no 
other is registered), the P-CSCF removes the security association established between the P-CSCF and 
the UE. Therefore further SIP signalUng (e.g. the NOTIFY request containing the deregistration event) 
will not reach the UE. 

5.2.5.2 Network-Initiated deregistration 

Upon receipt of a NOTIFY request on the dialog which was generated during subscription to the reg event package as 
described in subclause 5.2.3, including one or more <registration> element(s) with the state attribute set to "terminated" 
the P-CSCF shall remove all stored information for these public user identities. 

Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" (i.e. 
all pubhc user identities are deregistered) and the Subscription-State header set to "terminated", the P-CSCF shall 
shorten the security associations towards the UE. 
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NOTE 1: The security association between the P-CSCF and the UE is shortened to a duration that will allow the 
NOTIFY request containing the deregistration event to reach the UE. 

NOTE 2: When the P-CSCF receives the NOTIFY request with Subscription-State header containing the value of 
"terminated", the P-CSCF considers the subscription to the reg event package terminated (i.e. as if the P- 
CSCF had sent a SUBSCRIBE request to the S-CSCF with an Expires header containing a value of zero). 

5.2.6 General treatment for all dialogs and standalone transactions 
excluding the REGISTER method 

5.2.6.1 Introduction 

The procedures of subclause 5.2.6 and its subclauses are general to all requests and responses, except those for the 
REGISTER method. 

5.2.6.2 Determination of mobile-originated or mobile-terminated case 

Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the P-CSCF shall: 

perform the procedures for the mobile-terminating case as described in subclause 5.2.6.4 if the request makes use 
of the information for mobile-terminating calls, which was added to the Path header entry of the P-CSCF during 
registration (see subclause 5.2.2), e.g. the message is received at a certain port or the topmost Route header 
contains a specific user part or parameter; 

- perform the procedures for the mobile-originating case as described in subclause 5.2.6.3 if this information is not 
used by the request. 

5.2.6.3 Requests initiated by the UE 

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the request 
contains a P-Preferred-Identity header that matches one of the registered public user identities, the P-CSCF shall 
identify the initiator of the request by that public user identity. 

When the P-CSCF receives an initial request for a dialog or a request for a standalone transaction, and the request 
contains as P-Preferred-Identity header that does not match one of the registered pubUc user identities, or does not 
contain a P-Preferred-Identity header, the P-CSCF shall identify the initiator of the request by a default public user 
identity. If there is more then one default public user identity available, the P-CSCF shall randomly select one of them. 

NOTE 1: The contents of the From header do not form any part of this decision process. 

When the P-CSCF receives from the UE an initial request for a dialog, and a Service-Route header list exists for the 
initiator of the request, the P-CSCF shall: 

1) verify that the list of URIs received in the Service-Route header (during the last successful registration or re- 
registration) matches the preloaded Route headers in the received request. This verification is done on a per URI 
basis, not as a whole string. If the verification fails, then the P-CSCFshaU either: 

a) return a 400 (Bad Request) response that may include a Warning header containing the warn-code 399; the P- 
CSCF shall not forward the request, and shall not continue with the execution of steps 2 onwards; or 

b) replace the preloaded Route header value in the request with the value of the Service-Route header received 
during the last 200 (OK) response for a registration or reregistration; 

2) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the port 
number of the P-CSCF in accordance with the procedures of RFC3261 [26], and either: 

a) the P-CSCF FQDN that resolves to the IP address, or 

b) the P-CSCF IP address; 

3) add its own SIP URI to the top of the Record-Route header. The P-CSCF SIP URI is built in a format that 
contains the port number of the P-CSCF where it awaits subsequent requests from the called party, and either: 
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a) the P-CSCF FQDN that resolves to the IP address; or 

b) the P-CSCF IP address; 

4) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value 
representing the initiator of the request; 

5) add a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]; and 

6) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the 
request such that the P-CSCF is able to release the session if needed; 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives a Ixx or 2xx response to the above request, the P-CSCF shall: 

1) store the values received in the P-Charging-Function- Addresses header; 

2) store the list of Record-Route headers from the received response; 

3) store the dialog ID and associate it with the private user identity and public user identity involved in the session; 

4) rewrite the port number of its own Record Route entry to its own protected server port number negotiated with 
the calling UE, and append the comp parameter in accordance with the procedures of RFC 3486 [55]; and 

NOTE 2: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details on the selection of the protected port values see 3GPP TS 33.203 [19]. 

5) if the response corresponds to an INVITE request, save the Contact and Record-Route header field values 
received in the response such that the P-CSCF is able to release the session if needed; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives from the UE a target refresh request for a dialog, the P-CSCF shall: 

1) verify if the request relates to a dialog in which the originator of the request is involved: 

a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall 
answer the request by sending a 403 (Forbidden) response back to the originator. The response may include a 
Warning header containing the warn-code 399. The P-CSCF will not forward the request. No other actions 
are required; 

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue 
with the following steps; 

2) verify that the list of Route headers in the request matches the stored list of Record-Route headers for the same 
dialog. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P- 
CSCF shall either: 

a) return a 400 (Bad Request) response that may include a Warning header containing the warn-code 399; the P- 
CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or 

b) replace the Route header value in the request with the stored list of Record-Route headers for the same 
dialog; 

3) add its own address to the Via header. The P-CSCF Via header entry is built in a format that contains the port 
number of the P-CSCF where it awaits the responses to come, and either: 

a) the P-CSCF FQDN that resolves to the IP address, or 

b) the P-CSCF IP address; 

4) add its own SIP URI to the top of Record-Route header. The P-CSCF SIP URI is built in a format that contains 
the port number of the P-CSCF where it awaits subsequent requests from the called party, and either: 

a) the P-CSCF FQDN that resolves to the IP address; or 
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b) the P-CSCF IP address; and 

5) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the P-CSCF is able to release the session if needed; 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives a Ixx or 2xx response to the above request, the P-CSCF shall: 

1) store the list of Record-Route headers from the received response; 

2) rewrite the port number of its own Record Route entry to its own protected server port number negotiated with 
the calling UE, and append the comp parameter in accordance with the procedures of RFC 3486 [55]; and 

NOTE 3: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details on the selection of the protected port value see 3GPP TS 33.203 [19]. 

3) if the response corresponds to an INVITE request, save the Contact and Record-Route header field values 
received in the response such that the P-CSCF is able to release the session if needed; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives from the UE the request for a standalone transaction, and a Service-Route header list exists 
for the initiator of the request, the P-CSCF shall: 

1) verify that the list of URIs received in the Service-Route header (during the last successful registration or re- 
registration) matches the preloaded Route headers in the received request. This verification is done on a per URI 
basis, not as a whole string. If the verification fails, then the P-CSCFshaU either: 

a) return a 400 (Bad Request) response that may include a Warning header containing the warn-code 399; the P- 
CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or 

b) replace the preloaded Route header value in the request with the one received during the last registration in 
the Service-Route header of the 200 (OK) response; 

2) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value 
representing the initiator of the request; and 

3) add a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]; 
before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) store the values received in the P-Charging-Function- Addresses header; 

before forwarding the response to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including requests 
relating to an existing dialog where the method is unknown), the P-CSCF shall: 

1) verify if the request relates to a dialog in which the originator of the request is involved: 

a) if the request does not relates to an existing dialog in which the originator is involved, then the P-CSCF shall 
answer the request by sending a 403 (Forbidden) response back to the originator. The response may include a 
Warning header containing the warn-code 399. The P-CSCF will not forward the request. No other actions 
are required; 

b) if the request relates to an existing dialog in which the originator is involved, then the P-CSCF shall continue 

with the following steps; 

2) verify that the list of Route headers in the request matches the stored hst of Record-Route headers for the same 
dialog. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P- 
CSCF shall either: 

a) return a 400 (Bad Request) response that may include a Warning header containing the warn-code 399; the P- 
CSCF shall not forward the request, and shall not continue with the execution of steps 3 onwards; or 
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b) replace the Route header value in the request with the stored Ust of Record-Route headers for the same 

dialog; and 

3) for dialogs that are not INVITE dialogs, add a P-Charging- Vector header with the icid parameter populated as 
specified in 3GPP TS 32.225 [17]; 

before forwarding the request, (based on the topmost Route header,) in accordance with the procedures of 
RFC 3261 [26]. 

When the P-CSCF receives from the UE the request for an unknown method (that does not relate to an existing dialog), 
and a Service-Route header Ust exists for the initiator of the request, the P-CSCF shall: 

1) verify that the list of URIs received in the Service-Route header (during the last successful registration or re- 
registration) is included, preserving the same order, as a subset of the preloaded Route headers in the received 
request. This verification is done on a per URI basis, not as a whole string. If the verification fails, then the P- 
CSCF shall either: 

a) return a 400 (Bad Request) response that may include a Warning header containing the warn-code 399; the P- 
CSCF shall not forward the request, and shall not continue with the execution of steps 2 onwards; or 

b) replace the Route header value in the request with the one received during the last registration in the Service- 
Route header of the 200 (OK) response; and 

2) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with a value 
representing the initiator of the request; 

before forwarding the request, based on the topmost Route header, in accordance with the procedures of RFC 3261 [26]. 

5.2.6.4 Requests terminated by the UE 

When the P-CSCF receives, destined for the UE, an initial request for a dialog, prior to forwarding the request, the P- 
CSCF shaU: 

1) remove its own SIP URI from the topmost Route header; 

2) convert the list of Record-Route header values into a Ust of Route header values and save this list of Route 

headers; 

3) if the request is an INVITE request, save a copy of the Contact, CSeq and Record-Route header field values 
received in the request such that the P-CSCF is able to release the session if needed; 

4) add its own SIP URI to the top of the Ust of Record-Route headers and save the Ust. The P-CSCF SIP URI is 
built in a format that contains the comp parameter in accordance with the procedures of RFC 3486 [55], and the 
protected server port number of the security association establisUed from tUe UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association estabUsUed from tUe UE to tUe 

P-CSCF; or 

b) the P-CSCF IP address of the security association estabUsUed from tUe UE to tUe P-CSCF; 

5) add its own address to the top of the received list of Via header and save the list. The P-CSCF Via header entry 
is built in a format that contains the comp parameter in accordance with the procedures of RFC 3486 [55], and 
the protected server port number of the security association establisUed from tUe UE to tUe P-CSCF and eitUer: 

a) tUe P-CSCF FQDN tUat resolves to tUe IP address of tUe security association estabUsUed from tUe UE to tUe 
P-CSCF; or 

b) tUe P-CSCF IP address of tUe security association estabUsUed from tUe UE to tUe P-CSCF; 

NOTE 1: TUe P-CSCF associates two ports, a protected client port and a protected server port, witU eacU pair of 
security associations. For details of tUe usage of tUe two ports see 3GPP TS 33.203 [19]. 

6) store tUe values received in tUe P-CUarging-Function- Addresses Ueader; 

7) remove and store tUe icid parameter received in tUe P-CUarging- Vector Ueader; and 
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8) save a copy of the P-Called-Party-ID header; 
before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives a Ixx or 2xx response to the above request, the P-CSCF shall: 

1) remove the P-Preferred-Identity header, if present, and insert a P-Asserted-Identity header with the value saved 
from the P-Called-Party-ID header that was received in the request; 

2) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

3) verify that the list of URls received in the Record-Route header of the request corresponding to the same dialog 
is included, preserving the same order, as a subset of the Record-Route header Ust of this response. This 
verification is done on a per URI basis, not as a whole string. If the verification fails, then the P-CSCF shall 
either: 

a) discard the response; or 

b) replace the Record-Route header values with those received in the request, rewrite the port number of its own 
Record-Route entry to the port number where it awaits subsequent requests from the calling party and 
remove the comp parameter. 

If the verification is successful, the P-CSCF shall rewrite the port number of its own Record-Route entry to 
the port number where it awaits subsequent requests from the calling party and remove the comp parameter; 

4) store the dialog ID and associate it with the private user identity and public user identity involved in the session; 
and 

5) if the response corresponds to an INVITE request, save the Contact and Record-Route header field value 
received in the response such that the P-CSCF is able to release the session if needed; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any other response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to forwarding the request, 
the P-CSCF shall: 

1) remove its own SIP URI from the topmost Route header value; 

2) add its own address to the top of the received hst of Via header and save the list. The P-CSCF Via header entry 
is built in a format that contains the comp parameter in accordance with the procedures of RFC 3486 [55], and 
the protected server port number of the security association established from the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association estabhshed from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; and 

NOTE 2: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 
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3) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the P-CSCF is able to release the session if needed; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If the verification fails, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

2) rewrite the port number of its own Record-Route entry to the port number where it awaits subsequent requests 
from the calling party and remove the comp parameter; and 

3) if the response corresponds to an INVITE request, save the Contact and Record-Route header field values 
received in the response such that the P-CSCF is able to release the session if needed; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives, destined for the UE, a request for a standalone transaction, or a request for an unknown 
method (that does not relate to an existing dialog), prior to forwarding the request, the P-CSCF shall: 

1) add its own address to the top of the received list of Via header and save the list. The P-CSCF Via header entry 
is built in a format that contains the comp parameter in accordance with the procedures of RFC 3486 [55], and 
the protected server port number of the security association established from the UE to the P-CSCF and either: 

a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 
P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; 

NOTE 3: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) store the values received in the P-Charging-Function- Addresses header; and 

3) remove and store the icid parameter received in the P-Charging-Vector header; 
before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 
When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved Ust of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; and 

2) remove the P-Preferred-ldentity header, if present, and insert an P-Asserted-ldentity header with the value saved 
from Request-URI of the request; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target refresh request 
(including requests relating to an existing dialog where the method is unknown), prior to forwarding the request, the P- 
CSCF shall: 

1) add its own address to the top of the received Ust of Via header and save the Ust The P-CSCF Via header entry is 
built in a format that contains the comp parameter in accordance with the procedures of RFC 3486 [55], and the 
protected server port number of the security association established from the UE to the P-CSCF and either: 
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a) the P-CSCF FQDN that resolves to the IP address of the security association established from the UE to the 

P-CSCF; or 

b) the P-CSCF IP address of the security association established from the UE to the P-CSCF; and 

NOTE 4: The P-CSCF associates two ports, a protected client port and a protected server port, with each pair of 
security associations. For details of the usage of the two ports see 3GPP TS 33.203 [19]. 

2) remove and store the icid parameter from P-Charging-Vector header; 

before forwarding the request to the UE in accordance with the procedures of RFC 3261 [26]. 

When the P-CSCF receives any response to the above request, the P-CSCF shall: 

1) verify that the list of Via headers matches the saved list of Via headers received in the request corresponding to 
the same dialog, including the P-CSCF via header value. This verification is done on a per Via header value 
basis, not as a whole string. If these lists do not match, then the P-CSCF shall either: 

a) discard the response; or 

b) replace the Via header values with those received in the request; 

before forwarding the response in accordance with the procedures of RFC 3261 [26]. 

5.2.7 Initial INVITE 

5.2.7.1 Introduction 

In addition to following the procedures for initial requests defined in subclause 5.2.6, initial INVITE requests also 
foUow the procedures of this subclause. 

5.2.7.2 Mobile-originating case 

The P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response. 

Upon receiving a response as specified in RFC 3313 [31] to the initial INVITE request, the P-CSCF shall: 

if a media authorization token is generated by the PDF (i.e. when service-based local policy control is applied), 
insert the P-Media- Authorization header containing that media authorization token. 

NOTE: Typically, the first 183 (Session Progress) response contains an SDP answer including one or more "m=" 
media descriptions, but it is also possible that the response does not contain an SDP answer or the SDP 
does not include at least an "m=" media description. However, the media authorization token is generated 
independently of the presence or absence of "m=" media descriptions and sent to the UE in the P-Media- 
Authorization header value. The same media authorization token is used until the session is terminated. 

When the P-CSCF sends the UPDATE request towards the S-CSCF, the P-CSCF shall also include the access-network- 
charging-info parameter in the P-Charging- Vector header. See subclause 5.2.7.4 for further information on the access 
network charging information. 

5.2.7.3 Mobile-terminating case 

When the P-CSCF receives an initial INVITE request destined for the UE, it will contain the URI of the UE in the 

Request-URl, and a single preloaded Route header. The received initial INVITE request will also have a list of Record- 
Route headers. Prior to forwarding the initial INVITE to the URI found in the Request-URl, the P-CSCF shall: 

- if a media authorization token is generated by the PDF as specified in RFC 3313 [3 1] (i.e. when service-based 
local policy control is applied), insert the P-Media- Authorization header containing that media authorization 
token. 
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NOTE: Typically, the initial INVITE request contains an SDP offer including one or more "m=" media 

descriptions, but it is also possible that the INVITE request does not contain an SDP offer or the SDP 
does not include at least an "m= media description. However, the media authorization token is generated 
independently of the presence or absence of "m=" media descriptions and sent to the UE in the P-Media- 
Authorization header value. The same media authorization token is used until the session is terminated. 

In addition, the P-CSCF shall respond to all INVITE requests with a 100 (Trying) provisional response. 

When the P-CSCF sends 180 (Ringing) or 200 (OK) (to INVITE) towards the S-CSCF, the P-CSCF shaU also include 
the access-network-charging-info parameter in the P-Charging- Vector header. See subclause 5.2.7.4 for further 
information on the access network charging information. 

5.2.7.4 Access network charging information 

The P-CSCF shall include the access-network-charging-info parameter within the P-Charging- Vector header as 
described in subclause 7.2A.5. 

5.2.8 Call release 

5.2.8.1 P-CSCF-initiated call release 

5.2.8.1 .1 Cancellation of a session currently being establislied 

Upon receipt of an indication that radio coverage is no longer available for a served user, for whom one ore more 
ongoing multimedia session are currently being established, the P-CSCF shall cancel the related dialogs by sending out 
a CANCEL request according to the procedures described in RFC 3261 [26]. 

5.2.8.1 .2 Release of an existing session 

Upon receipt of an indication that the radio interface resources are no longer available for a served user, for whom one 
or more ongoing session exists, the P-CSCF shall release each of the related dialogs by applying the following steps: 

1) if the P-CSCF serves the calling user of a session it shall generate a BYE request based on the information saved 
for the related dialog, including: 

- a Request-URI, set to the stored Contact header provided by the called user; 

- a To header, set to the To header value as received in the 200 (OK) response for the initial INVITE request; 

- a From header, set to the From header value as received in the initial INVITE request; 

- a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

- a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user, 
incremented by one; 

- a Route header, set to the routeing information towards the called user as stored for the dialog; 

- fiirther headers, based on local policy or the requested session release reason. 

2) If the P-CSCF serves the called user of a session it shall generate a BYE request based on the information saved 
for the related dialog, including: 

- a Request-URI, set to the stored Contact header provided by the calling user; 

- a To header, set to the From header value as received in the initial INVITE request; 

- a From header, set to the To header value as received in the 200 (OK) response for the initial INVITE 
request; 

- a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 
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a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user, 
incremented by one - if no CSeq value was stored for that session it shall generate and apply a random 
number within the valid range for CSeqs; 

- a Route header, set to the routeing information towards the calling user as stored for the dialog; 

- further headers, based on local policy or the requested session release reason. 

3) send the so generated BYE request towards the indicated user. 

4) upon receipt of the 2xx responses for the BYE request, shall delete all information related to the dialog and the 
related multimedia session. 

5.2.8.1.3 Abnormal cases 

Upon receipt of a request on a dialog for which the P-CSCF initiated session release, the P-CSCF shall terminate this 
received request and answer it with a 481 (Call/Transaction Does Not Exist) response. 

5.2.8.1 .4 Release of the existing dialogs due to registration expiration and deletion of the 
security association 

If there are still active dialogs associated with the user after the security associations were deleted, the P-CSCF shall 
discard all information pertaining to these dialogs without performing any further SIP transactions with the peer entities 
of the P-CSCF. 

NOTE: At the same time, the P-CSCF will also indicate via the Go interface that all resources associated with 
these dialogs should be released. 

5.2.8.2 Call release initiated by any other entity 

When the P-CSCF receives a 2xx response for a BYE request matching an existing dialog, it shall delete all the stored 
information related to the dialog. 

5.2.9 Subsequent requests 

5.2.9.1 Mobile-originating case 

The P-CSCF shall respond to all relNVITE requests with a 100 (Trying) provisional response. 

For a relNVITE request from the UE, when the P-CSCF sends the UPDATE request towards the S-CSCF, the P-CSCF 
shall include the updated access-network-charging-info parameter in the P-Charging- Vector header. See 
subclause 5.2.7.4 for further information on the access network charging information. 

5.2.9.2 Mobile-terminating case 

The P-CSCF shall respond to all relNVITE requests with a 100 (Trying) provisional response. 

For a relNVITE request destined towards the UE, when the P-CSCF sends 200 (OK) response (to the INVITE request) 
towards the S-CSCF, the P-CSCF shall include the updated access-network-charging-info parameter in the P-Charging- 
Vector header. See subclause 5.2.7.4 for fiu-ther information on the access network charging information. 

5.2.10 Emergency service 

The P-CSCF shall store a configurable list of local emergency numbers and emergency URls, i.e. those used for 
emergency services by the operator to which the P-CSCF belongs to. In addition to that, the P-CSCF shall store a 
configurable list of roaming partners' emergency numbers and emergency URls associated with MCC and MNC codes. 

NOTE: Certain SIP URls may be classified as emergency URls in all networks. 

The P-CSCF shall inspect the Request URl of all INVITE requests from the UE for known emergency numbers and 
emergency URls from these configurable lists. If the P-CSCF detects that the Request-URl of the INVITE request 
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matches one of the numbers in any of these lists, the P-CSCF shall not forward the ESTVITE request. The P-CSCF shall 
respond the INVITE request with a 380 (Alternative Service) response. 

In order to determine whether the INVITE request is destined for an emergency centre in the roaming country (i.e. the 
list of roaming partners' are inspected), the P-CSCF shall compare the MCC and the MNC fields in the received in the 
P-Access-Network-Info header of the INVITE request against its own MCC and MNC codes. 

The P-CSCF shall include in the 380 (Alternative Service) response a Content-Type header field with the value set to 
associated MIME type of the 3GPP IMS XML body as described in subclause 7.6.1. 

The P-CSCF shall include in the 3GPP IMS XML body: 

a) an <altemative-service> element, set to the parameters of the alternative service: 

b) a <type> child element, set to "emergency" to indicate that it was an emergency call; and 

c) a <reason> child element, set to an operator configurable reason. 

5.2.11 Void 

5.3 Procedures at the l-CSCF 
5.3.1 Registration procedure 

5.3.1.1 General 

During the registration procedure the l-CSCF shall behave as a stateful proxy. 

5.3.1.2 Normal procedures 

When I-CSCF receives a REGISTER request, the I-CSCF starts the user registration status query procedure to the HSS 
as specified in 3GPP TS 29.228 [14]. 

Prior to performing the user registration query procedure to the HSS, the l-CSCF decides which HSS to query, possibly 
as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 3GPP TS 29.228 [14]. 

If the user registration status query response from the HSS includes a vaUd SIP URI, the I-CSCF shall: 

1) replace the Request-URI of the received REGISTER request with the SIP URI received from the HSS in the 

Server-Name AVP; 

2) apply the procedures as described in subclause 5.3.3 if topology hiding is required; and 

3) forward the REGISTER request to the indicated S-CSCF. 

If the user registration status query response from the HSS includes a list of capabilities, the I-CSCF shall: 

1) select a S-CSCF that fulfils the indicated mandatory capabilities - if more then one S-CSCFs fulfils the indicated 
mandatory capabiUties the S-CSCF which fulfils most of the possibly additionally indicated optional capabiUties; 

2) replace the Request-URI of the received REGISTER request with the URI of the S-CSCF; 

3) apply the procedures as described in subclause 5.3.3 if topology hiding is required; and 

4) forward the REGISTER request to the selected S-CSCF. 

When the I-CSCF receives a 2xx response to a REGISTER request, the I-CSCF shall proxy the 2xx response to the P- 
CSCF. 
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5.3.1.3 



Abnormal cases 



In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 403 
(Forbidden) response to the UE. The response may include a Warning header containing the wam-code 399. 

If the HSS sends a negative response to the user registration status query request, the 1-CSCF shall send back a 403 
(Forbidden) response. The response may include a Warning header containing the warn-code 399. 

If the the user registration status query procedure cannot be completed, e.g. due to time-out or incorrect information 
from the HSS, the I-CSCF shall send back a 480 (Temporarily Unavailable) response to the UE. 

If a selected S-CSCF: 

does not respond to the REGISTER request and its retransmissions by the I-CSCF; or 

- sends back a 3xx response or 480 (Temporarily Unavailable) response; 

the I-CSCF shall select a new S-CSCF as described in subclause 5.3.1.2, based on the capabilities indicated from the 
HSS. The newly selected S-CSCF shall not be one of any S-CSCFs selected previously during this same registration 
procedure. 

If the I-CSCF cannot select a S-CSCF which fulfils the mandatory capabilities indicated by the HSS, the I-CSCF shall 
send back a 600 (Busy Everywhere) response to the user. 



The I-CSCF may behave as a stateful proxy for initial requests. 

When the I-CSCF receives an initial request for a dialog or standalone transaction, that does not contain a Route header, 
the I-CSCF shall start the user location query procedure to the HSS as specified in 3GPP TS 29.228 [14] for the called 
user, indicated in the Request-URI. Prior to performing the user location query procedure to the HSS, the I-CSCF 
decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as 
specified in 3GPP TS 29.228 [14]. 

Upon successful user location query, when the response contains the URI of the assigned S-CSCF, the I-CSCF shall: 

1) insert the URI received from the HSS as the topmost Route header; 

2) store the value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in 
the P-Charging- Vector header. If no icid parameter was found, then create a new, globally unique value for the 
icid parameter and insert it into the P-Charging- Vector header; 

3) apply the procedures as described in subclause 5.3.3 if topology hiding is required; and 

4) forward the request based on the topmost Route header. 

Upon successful user location query, when the response contains information about the required S-CSCF capabilities, 
the I-CSCF shall: 

1) select a S-CSCF according to the method described in 3GPP TS 29.228 [14]; 

2) insert the URI of the selected S-CSCF as the topmost Route header field value; 

3) execute the procedure described in step 2 and 3 in the above paragraph (upon successful user location query, 
when the response contains the URI of the assigned S-CSCF); and 

4) forward the request to the selected S-CSCF. 

Upon an unsuccessful user location query when the response from the HSS indicates that the user does not exist, the I- 
CSCF shall return an appropriate unsuccessful SIP response. This response may be a 404 (Not found) or 604 (Does not 
exist anywhere) in the case the user is not a user of the home network. 



5.3.2 



Initial requests 



5.3.2.1 



Normal procedures 
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Upon an unsuccessful user location query when the response from the HSS indicates that the user is not registered and 
no services are provided for such a user, the I-CSCF shall return an appropriate unsuccessful SIP response. This 
response may be a 480 (Temporarily unavailable) if the user is recognized as a valid user, but is not registered at the 
moment and it does not have services for unregistered users. 

When the I-CSCF receives an initial request for a dialog or standalone transaction, that contains a single Route header 
pointing to itself, the I-CSCF shall determine from the entry in the Route header whether it needs to do HSS query or 
hiding. In case HSS query is needed, then the I-CSCF shall perform the procedures described for the case when there is 
no Route header present. If the I-CSCF determines that hiding must be performed, then the THIG functionality in I- 
CSCF received an outgoing initial request for which topology hiding has to be applied, and the I-CSCF shall: 

1) remove its own SIP URI from the topmost Route header; 

2) perform the procedures described in subclause 5.3.3; and 

3) route the request based on the Request-URI header field. 

When the I-CSCF receives an initial request for a dialog or standalone transaction containing more than one Route 
header, the I-CSCF shaU: 

1) remove its own SIP URI from the topmost Route header; 

2) apply the procedures as described in subclause 5.3.3; and 

3) forward the request based on the topmost Route header. 

NOTE: In accordance with SIP the I-CSCF can add its own routeable SIP URI to the top of the Record-Route 

header to any request, independently of whether it is an initial request, or whether topology hiding is 
performed. The P-CSCF will ignore any Record-Route header that is not in the initial request of a dialog. 

When the I-CSCF receives a response to an initial request (e.g. 183 or 2xx), the I-CSCF shall store the values from the 
P-Charging-Function- Addresses header, if present. If the next hop is outside of the current network, then the I-CSCF 
shall remove the P-Charging-Function- Addresses header prior to forwarding the message. 

5.3.2.2 Abnormal cases 

In the case of SLF query, if the SLF does not send HSS address to the I-CSCF, the I-CSCF shall send back a 404 (Not 
Found) response to the UE. 

If the HSS sends a negative response to the user location query, the I-CSCF shall send back a 404 (Not Found) 
response. 

If the I-CSCF receives a CANCEL request and if the I-CSCF finds an internal state indicating a pending Cx transaction 
with the HSS, the I-CSCF: 

- shall answer the CANCEL with a 200 OK; 

- shall answer the original request with a 487 Request Terminated; and 

- shall silently discard the later arriving (pending) Cx answer message from the HSS. 

5.3.3 THIG functionality in the l-CSCF(THIG) 

5.3.3.1 General 

The following procedures shall only be appUed if topology hiding is required by the network. The network requiring 
topology hiding is called the hiding network. 

NOTE 1 : Requests and responses are handled independently therefore no state information is needed for that 
purpose within an I-CSCF(THIG). 

The I-CSCF(THIG) shall apply topology hiding to all headers which reveal topology information, such as Via, Route, 
Record-Route, Service-Route. 
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Upon receiving an incoming REGISTER request for which topology hiding has to be applied and which includes a Path 
header, the I-CSCF(THIG) shall add the routeable SIP URI of an I-CSCF(THIG) to the top of the Path header. The I- 
CSCF(THIG) may include in the inserted SIP URI an indicator that identifies the direction of subsequent requests 
received by the I-CSCF i.e., from the S-CSCF towards the P-CSCF, to identify the mobile-terminating case. The I- 
CSCF(THIG) may encode this indicator in different ways, such as, e.g., a unique parameter in the URI, a character 
string in the usemame part of the URI, or a dedicated port number in the URI. 

NOTE 2: Any subsequent request that includes the direction indicator (in the Route header) or arrives at the 
dedicated port number, indicates that the request was sent by the S-CSCF towards the P-CSCF. 

Upon receiving an incoming initial request for which topology hiding has to be applied and which includes a Record- 
Route header, the I-CSCF(THIG) shall add its own routeable SIP URI to the top of the Record-Route header. 

Upon receiving an outgoing initial request for which topology hiding has to be applied and which includes P-Charging- 
Function- Addresses header, the I-CSCF(THIG) shall remove the P-Charging-Function-Addresses header prior to 
forwarding the message. 

5.3.3.2 Encryption for topology hiding 

Upon receiving an outgoing request/response from the hiding network the I-CSCF(THIG) shall perform the encryption 
for topology hiding purposes, i.e. the I-CSCF(THIG) shall: 

1) use the whole header values which were added by one or more specific entity of the hiding network as input to 
encryption, besides the UE entry; 

2) not change the order of the headers subject to encryption when performing encryption; 

3) use for one encrypted string all received consecutive header entries subject to encryption, regardless if they 
appear in separate consecutive headers or if they are consecutive entries in a comma separated list in one header; 

4) construct an NAI in the form of 'username@realm', where the usemame part is the encrypted string, and the 
realm is the name of the encrypting network. 

5) append a "tokenized-by=" tag and set it to the value of the encrypting network's name, after the constructed NAI; 

6) form one valid entry for the specific header out of the resulting NAI, e.g. prepend "SIP/2.0/UDP" for Via 
headers or "sip:" for Route and Record-Route headers. 

NOTE 1 : Even if consecutive entries of the same network in a specific header are encrypted, they will result in only 
one encrypted header entry. For example: 

Via: SIP/2. 0/UDP icscf l_s . homel . net ; Ir , 

SIP/2. 0/UDP Token( SIP/2. 0/UDP scscfl . homel . net ; Ir, 

SIP/2 .0/UDP pcscfl .homel .net; Ir) ghomel .net; 
tokenized-by=homel .net, 
SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] 

NOTE 2: If multiple entries of the same network are within the same type of headers, but they are not consecutive, 
then these entries will be tokenized to different strings. For example: 

Route : sip : icscf l_s . homel . net ; ir , 

sip : Token (sip:scscfl. homel . net ; Ir ) @homel . net ; tokenized-by=homel . net, 

sip : asl . foreign . net; Ir, 

sip : Token ( sip : scscfl . homel . net ; Ir , 

sip : pcscfl . homel . net; Ir ) Shomel . net ; tokenized-by=homel . net, 
sip: [5555: : aaa : bbb : ccc : ddd] 

5.3.3.3 Decryption for Topology Hiding 

Upon receiving and incoming requests/response to the hiding network the I-CSCF(THIG) shall perform the decryption 
for topology hiding purposes, i.e. the I-CSCF shall: 

1) identify NAIs encrypted by the network this I-CSCF belongs to within all headers of the incoming message; 

2) use the user part of those NAIs that carry the identification of the hiding network within the value of the 
tokenized-by tag as input to decryption; 
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3) use as encrypted string the user part of the NAI which follows the sent-protocol (for Via Headers, e.g. 
"SIP/2. 0/UDP") or the URI scheme (for Route and Record-Route Headers, e.g. "sip:"); 

4) replace all content of the received header which carries encrypted information with the entries resulting from 
decryption. 

EXAMPLE: An encrypted entry to a Via header that looks like: 

Via: SIP/2. 0/UDP Token (SIP/2 . 0/UDP scscf 1 . homel . net ; Ir, 

SIP/2 . 0/UDP pcscf 1 . homel . net ; Ir ) Shomel . net ; tokenized-by=homel . net 

will be replaced with the following entries: 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; ir, SIP/2. 0/UDP pcscf 1 . homel . net ; Ir 

NOTE: Motivations for these decryption procedures are e.g. to allow the correct routeing of a response through 
the hiding network, to enable loop avoidance within the hiding network, or to allow the entities of the 
hiding network to change their entries within e.g. the Record-Route header. 



5.3.4 Void 



5.4 Procedures at the S-CSCF 
5.4.1 Registration and autlientication 

5.4.1.1 Introduction 

The S-CSCF shall act as the SIP registrar for all UAs of the IM CN subsystem with public user identities. 

The S-CSCF shall support the use of the Path and Service-Route header. The S-CSCF must also support the Require 
and Supported headers. The Path header is only applicable to the REGISTER request and its 200 (OK) response. The 
Service-Route header is only applicable to the 200 (OK) response of REGISTER. 

The network operator defines minimum and maximum times for each registration. These values are provided within the 
S-CSCF. 

The procedures for notification concerning automatically registered public user identities of a user are described in 
subclause 5.4.2.1.2. 



5.4.1.2 



Initial registration and user-initiated reregistration 



5.4.1.2.1 



Unprotected REGISTER 



NOTE 1 : Any REGISTER request sent unprotected by the UE is considered to be an initial registration. A 200 
(OK) final response to such a request will only be sent back after the S-CSCF receives a correct 
authentication challenge response in a REGISTER request that is sent integrity protected. 

NOTE 2: A REGISTER with Expires header value equal to zero should always be received protected. However, it 
is possible that in error conditions a REGISTER with Expires header value equal to zero may be received 
unprotected. In that instance the procedures below will be applied. 

When the S-CSCF receives a new unprotected registration request for an already registered public user identity linked 
to the same private user identity but with a new contact information (e.g. a user roams to a different network without de- 
registering the previous one), the S-CSCF shall: 

1) perform the procedure for 'receipt of a REGISTER request without an "integrity-protected" parameter, 
or with the "integrity-protected" parameter in the Authorization header set to "no"', for the received public 

user identity; and 

2) if the authentication has been successful and if the previous registration has not expired, the S-CSCF 
shall perform the network initiated de-registration procedure only for the previous contact information as 
described in subclause 5.4.1.5. 
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Upon receipt of a REGISTER request without an "integrity-protected" parameter, or with the "integrity-protected" 
parameter in the Authorization header set to "no", the S-CSCF shall: 

1) identify the user by the public user identity as received in the To header and the private user identity as received 
in the username field in the Authorization header of the REGISTER request; 

2) check if the P-Visited-Network header is included in the REGISTER request, and if it is included identify the 
visited network by the value of this header; 

3 select an authentication vector for the user. If no authentication vector for this user is available, after the S-CSCF 
has performed the Cx Multimedia Authentication procedure with the HSS, as described in 3GPP TS 29.229 [15], 
the S-CSCF shall select an authentication vector as described in 3GPP TS 33.203 [19]. 

Prior to performing Cx Multimedia Authentication procedure with the HSS, the S-CSCF decides which HSS to 
query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in 
3GPPTS 29.228 [14]; 

NOTE 3: At this point the S-CSCF informs the HSS, that the user currently registering will be served by the S- 
CSCF by passing its SIP URI to the HSS. This will be indicated by the HSS for all further incoming 
requests to this user, in order to direct all these requests directly to this S-CSCF. 

4) store the icid parameter received in the P-Charging-Vector header; 

5) challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request, including a 
WWW-Authenticate header which transports: 

the home network identification in the realm field; 

the RAND and AUTN parameters and optional server specific data for the UE in the nonce field; 
the security mechanism, which is AKAvl-MD5, in the algorithm field; 

- the IK (Integrity Key) parameter for the P-CSCF in the ik field (see subclause 7.2A. 1); and 

- the CK (Cipher Key) parameter for the P-CSCF in the ck field (see subclause 7.2A.1); 

6) store the RAND parameter used in the 401 (Unauthorized) response for future use in case of a resynchronisation. 
If a stored RAND akeady exists in the S-CSCF, the S-CSCF shall overwrite the stored RAND with the RAND 
used in the most recent 401 (Unauthorized) response; 

7) send the so generated 401 (Unauthorized) response towards the UE; and, 

8) start timer reg-await-auth which guards the receipt of the next REGISTER request. 

If the received REGISTER request indicates that the challenge sent previously by the S-CSCF to the UE was deemed to 
be invalid by the UE, the S-CSCF shall stop the timer reg-await-auth and proceed as described in the 
subclause 5.4.1.2.3. 

5.4.1.2.2 Protected REGISTER 

Upon receipt of a REGISTER request with the "integrity-protected" parameter in the Authorization header set to "yes", 
the S-CSCF shall identify the user by the pubUc user identity as received in the To header and the private user identity 
as received in the Authorization header of the REGISTER request, and: 

In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is running): 

1) check if the user needs to be reauthenticated. 

The S-CSCF may require authentication of the user for any REGISTER request, and shall always require 
authentication for REGISTER requests received without the "integrity-protected" parameter in the Authorization 
header set to "yes". 

If the user needs to be reauthenticated, the S-CSCF shall proceed with the procedures as described for the initial 
REGISTER in subclause 5.4.1.2.1, beginning with step 4). If the user does not need to be reauthenticated, the S- 
CSCF shall proceed with the following steps in this paragraph; and 
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2) check whether an Expires timer is included in the REGISTER request and its value. If the Expires header 

indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in subclause 5.4.1.4. 
If the Expires header does not indicate zero, the S-CSCF shall check whether the public user identity received in 
the To header is already registered. If it is not registered, the S-CSCF shall proceed beginning with step 5 below. 
Otherwise, the S-CSCF shall proceed beginning with step 6 below. 

In the case that a timer reg-await-auth is running for this user the S-CSCF shall: 

1) check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried 
the last challenge. The S-CSCF shall only proceed further if the Call-IDs match. 

2) stop timer reg-await-auth; 

3) check whether an Authorization header is included, containing: 

a) the private user identity of the user in the username field; 

b) the algorithm which is AKAvl-MD5 in the algorithm field; and 

c) the authentication challenge response needed for the authentication procedure in the response field. 

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge 
response was included; 

4) check whether the received authentication challenge response and the expected authentication challenge 
response (calculated by the S-CSCF using XRES and other parameters as described in RFC 3310 [49]) match. 
The XRES parameter was received from the HSS as part of the Authentication Vector. The S-CSCF shall only 
proceed with the following steps if the challenge response received from the UE and the expected response 
calculated by the S-CSCF match; 

5) after performing the Cx Server Assignment procedure with the HSS, as described in 3GPP TS 29.229 [15], store 
the following information in the local data: 

a) the Ust of public user identities associated to the user, including the own public user identity under 
registration and the implicitly registered due to the received REGISTER request. Each public user identity is 
identified as either barred or non-barred; and, 

b) all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), 
including initial Filter Criteria; 

NOTE 1: There might be more than one set of initial Filter Criteria received because some implicitly registered 

public user identities that are part of the same user's subscription may belong to different service profiles. 

6) bind to each non-barred registered public user identity all registered contact information and store the related 
method tag values from the Contact header for future use; 

NOTE 2: There might be more then one contact information available for one public user identity. 

NOTE 3: The barred public user identities are not bound to the contact information. 

7) check whether a Path header was included in the REGISTER request and construct a list of preloaded Route 
headers from the list of entries in the Path header. The S-CSCF shall preserve the order of the preloaded Route 
headers and bind them to the contact information that was received in the REGISTER message; 

NOTE 4: If this registration is a reregistration, then a list of pre-loaded Route headers will already exist. The new 
list replaces the old list. 

8) determine the duration of the registration by checking the value of the Expires header in the received REGISTER 
request. The S-CSCF may reduce the duration of the registration due to local policy or send back a 423 (Interval 
Too Brief) response specifying the minimum allowed time for registration; 

9) store the icid parameter received in the P-Charging- Vector header; 

10) create a 200 (OK) response for the REGISTER request, including: 
a) the list of received Path headers; 
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b) a P-Associated-URI header containing the list of pubHc user identities that the user is authorized to use. The 
first URI in the Hst of public user identities supplied by the HSS to the S-CSCF will indicate the default 
public user identity to be used by the S-CSCF. The public user identity indicated as the default public user 
identity must be an already registered pubhc user identity. The S-CSCF shall place the default public user 
identity as a first entry in the list of URIs present in the P-Associated-URI header. The default public user 
identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity header, as 
described in subclause 5.2.6.3. The S-CSCF shall not add a barred public user identity to the hst of URIs in 
the P-Associated-URI header; 

c) a Service-Route header containing: 

- the SIP URI identifying the S-CSCF containing an indication that requests routed via the service route 
(i.e. from the P-CSCF to the S-CSCF) are treated as for the mobile-originating case. This indication may 
e.g. be in a URI parameter, a character string in the user part of the URI or be a port number in the URI; 

and, 

- if network topology hiding is required a SIP URI identifying an I-CSCF(THIG) as the topmost entry; and 

d) a P-Charging-Function-Addresses header containing the values received from the HSS if the P-CSCF is in 
the same network as the S-CSCF. It can be determined if the P-CSCF is in the same network as the S-CSCF 
by the contents of the P-Visited-Network-ID header field included in the REGISTER request; 

11) send the so created 200 (OK) response to the UE; 

12) send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter 
Criteria from the HSS for the REGISTER event; and, 

NOTE 5: If this registration is a reregistration, the Filter Criteria already exists in the local data. 

13) handle the user as registered for the duration indicated in the Expires header. 

5.4.1.2.3 Abnormal cases 

In the case that the authentication challenge response from the UE does not match with the expected authentication 
challenge response and the request has the "integrity-protected" parameter in the Authentication header set to "yes", the 
S-CSCF shall: 

- send a 403 (Forbidden) response to the UE. The S-CSCF shall consider this authentication attempt as failed. The 
S-CSCF shall not update the registration time of the subscriber. 

NOTE 1: If the UE was registered before, it stays registered until the registration expiration time expires. 

In the case that the REGISTER request, which was supposed to carry the response to the challenge, contains no 
authentication challenge response and no AUTS parameters indicating that the MAC parameter was invalid in the 
challenge, the S-CSCF shall: 

- respond with a 403 (Forbidden) response to the UE. The S-CSCF shall not update the registration time of the 
subscriber. 

NOTE 2: If the UE was registered before, it stays registered until the registration expiration time expires. 

In the case that the REGISTER request from the UE containing an authentication challenge response indicates that the 
authentication challenge was invalid (contains the AUTS parameter indicating this), the S-CSCF will fetch new 
authentication vectors from the HSS. In order to indicate a resynchronisation, the S-CSCF shall include the AUTS 
received from the UE and the stored RAND when fetching the new authentication vectors. On receipt of the new 
authentication vectors from the HSS, the S-CSCF shall either: 

- send a 401 (Unauthorized) response to initiate a further authentication attempt, using these new vectors; or 

respond with a 403 (Forbidden) response if the authentication attempt is to be abandoned. 

NOTE 3: Since the UE responds only to two consecutive challenges, the S-CSCF will send a 401 (Unauthorized) 
response that contains a new challenge only twice. 

In the case that the expiration timer from the UE is too short to be accepted by the S-CSCF, the S-CSCF shall: 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



53 



ETSI TS 124 229 V5.11.1 (2005-01) 



reject the REGISTER request with a 423 (Interval Too Brief) response, containing a Min-Expires header with 
the minimum registration time the S-CSCF will accept. 

On receiving a failure response to one of the third-party REGISTER requests, the S-CSCF may initiate network- 
initiated deregistration procedure based on the information in the Filter Criteria. If the Filter Criteria does not contain 
instruction to the S-CSCF regarding the failure of the contact to the AS, the S-CSCF shall not initiate network-initiated 

deregistration procedure. 

In the case that the REGISTER request from the UE contains more than one SIP URIs as Contact header entries, the S- 
CSCF shall only store the entry with the highest "q" value and include it in the 200 (OK) response. 

NOTE 4: If the timer reg-await-auth expires, the S-CSCF will consider the authentication to have failed. If the 
public user identity was already registered, the S-CSCF will leave it as registered described in 
3GPP TS 33.203 [19]. The operator's policy wiU specify when will, upon authentication failure, the 
currently registered public user identity or the user be de-registered by the S-CSCF. 

5.4.1 .3 Authentication and reautlientication 

Authentication and reauthentication is performed by the registration procedures as described in subclause 5.4.1.2. 

5.4.1.4 User-initiated deregistration 

When S-CSCF receives a REGISTER request with the Expires header field containing the value zero, the S-CSCF 
shall: 

- check whether the "integrity-protected" parameter in the Authorization header field is set to "yes", indicating that 
the REGISTER request was received integrity protected. The S-CSCF shall only proceed with the following 
steps if the "integrity-protected" parameter is set to "yes"; 

release each multimedia session which was initiated with the public user identity found in the P-Asserted- 
Identity header field or with one of the impUcitly registered public used identities by applying the steps Usted in 
subclause 5.4.5.1.2; 

- deregister the public user identity found in the To header field together with the implicitly registered public user 
identities; 

- send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter 
Criteria from the HSS for the REGISTER event; and 

if this is a deregistration request for the only public user identity currently registered with its associated set of 
implicitly registered pubUc user identities (i.e. no other is registered) and there are still active multimedia 
sessions associated with this user, release each multimedia session belonging to the served user by applying the 
steps listed in subclause 5.4.5.1.2. 

If all public user identities of the UE are deregistered, then the S-CSCF may consider the UE and P-CSCF subscriptions 
to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header containing 
a value of zero). 

If the Authorization header of the REGISTER request did not contain an "integrity-protected" parameter, or the 
"integrity-protected" parameter was set to the value "no", the S-CSCF shall apply the procedures described in 
subclause 5.4.1.2.1. 

On completion of the above procedures in this subclause and of the Cx Server Assignment procedure with the HSS, as 
described in 3GPP TS 29.229 [15], for one or more public user identities, the S-CSCF shall update or remove those 
public user identities, their registration state and the associated service profiles from the local data (based on operators' 
policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF allocated to this subscriber). 

5.4.1 .5 Network-initiated deregistration 

Prior to initiating the network-initiated deregistration for the only public user identity currently registered with its 
associated set of implicitly registered public user identities (i.e. no other is registered) while there are still active 
multimedia sessions belonging to this user, the S-CSCF shall release all multimedia sessions belonging to this user as 
described in subclause 5.4.5.1. 
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When a network-initiated deregistration event occurs for one or more public user identity, the S-CSCF shall send a 
NOTIFY request to all subscribers that have subscribed to the respective reg event package. Prior to sending the 
NOTIFY request, the S-CSCF shall release all sessions related to the public user identity being deregistered, if any. For 
each NOTIFY request, the S-CSCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the 
S-CSCF is aware of the user owns; 

4) set the aor attribute within each <registration> element to one public user identity: 

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact 
address provided by the UE; 

b) if the public user identity: 

i) has been deregistered then: 

- set the state attribute within the <registration> element to "terminated"; 

- set the state attribute within the <contact> element to "terminated"; and 

- set the event attribute within the <contact> element to "deactivated" if the S-CSCF expects the UE to 
reregister or "rejected" if the S-CSCF does not expect the UE to reregister; or 

ii) has been kept registered then: 

- set the state attribute within the <registration> element to "active"; and 
set the state attribute within the <contact> element to "active"; and 

5) add a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]. 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

Also, the S-CSCF shall send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that 
matches the Filter Criteria from the HSS for the REGISTER event. 

In case of the deregistration of the old contact information when the UE is roaming, registration is done in a new 
network and the previous registration has not expired, on completion of the above procedures, the S-CSCF shall remove 
the registration information related to the old contact from the local data. 

Otherwise, on completion of the above procedures in this subclause for one or more public user identities, the S-CSCF 
shall deregister those public user identities and the associated impUcitly registered public user identities. On completion 
of the Cx Server Assignment procedure with the HSS, as described in 3GPP TS 29.229 [15], the S-CSCF shall update 
or remove those public user identities, their registration state and the associated service profiles from the local data 
(based on operators' policy the S-CSCF can request of the HSS to either be kept or cleared as the S-CSCF allocated to 
this subscriber). On the completion of the Cx Registration-Termination procedure with the HSS, as described in 
3GPP TS 29.228 [14], the S-CSCF shall remove those public user identities, their registration state and the associated 
service profiles from the local data. 

5.4.1.6 Network-initiated reautlientication 

The S-CSCF may request a subscriber to reauthenticate at any time, based on a number of possible operator settable 
triggers as described in subclause 5.4.1.2. 

If the S-CSCF is informed that a private user identity needs to be re-authenticated, the S-CSCF shall generate a 
NOTIFY request on all dialogs which have been established due to subscription to the reg event package of that user. 
For each NOTIFY request the S-CSCF shall: 

1) set the Request-URI and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 
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3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the 
S-CSCF is aware of the user owns: 

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact 
address provided by the UE; 

b) set the aor attribute within each <registration> element to one public user identity; 

c) set the state attribute within each <registration> element to "active"; 

d) set the state attribute within each <contact> element to "active"; 

e) set the event attribute within each <contact> element to "shortened"; and 

f) set the expiry attribute within each <contact> element to an operator defined value; and 

4) set a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]. 
Afterwards the S-CSCF shall wait for the user to reauthenticate (see subclause 5.4.1.2). 

NOTE: Network initiated re-authentication may occur due to internal processing within the S-CSCF. 
The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

When generating the NOTIFY request, the S-CSCF shall shorten the validity of all registration lifetimes associated with 
this private user identity to an operator defined value that will allow the user to be re-authenticated. 

5.4.1 .7 Notification of Application Servers about registration status 

During registration, the S-CSCF shall include a P-Access-Network-Info header (as received in the REGISTER request 
from the UE) in the 3rd-party REGISTER sent towards the ASs, if the AS is part of the trust domain. If the AS is not 
part of the trust domain, the S-CSCF shall not include any P-Access-Network-Info header. The S-CSCF shall not 
include a P- Access-Network-Info header in any responses to the REGISTER request. 

If the registration procedure described in subclauses 5.4.1.2, 5.4.1.4 or 5.4.1.5 (as appropriate) was successful, the S- 
CSCF shall send a third-party REGISTER request to each AS with the following information: 

a) the Request-URI, which shall contain the AS's SIP URI; 

b) the From header, which shall contain the S-CSCF's SIP URI; 

c) the To header, which shall contain either the public user identity as contained in the REGISTER request received 
from the UE or one of the implicitly registered public user identities, as configured by the operator; 

d) the Contact header, which shall contain the S-CSCF's SIP URI; 

e) for initial registration and user-initiated reregistration (subclause 5.4.1.2), the Expires header, which shall 
contain the same value that the S-CSCF returned in the 200 (OK) response for the REGISTER request received 
form the UE; 

f) for user- initiated deregistration (subclause 5.4.1.4) and network-initiated deregistration (subclause 5.4.1.5), the 
Expires header, which shall contain the value zero; 

g) for initial registration and user-initiated reregistration (subclause 5.4.1.2), a message body, if there is Filter 
Criteria indicating the need to include HSS provided data for the REGISTER event (e.g. HSS may provide AS 
specific data to be included in the third-party REGISTER, such as IMSI to be deUvered to IM SSF). If there is a 
service information XML element provided in the HSS Filter Criteria for an AS (see 3GPP TS 29.228 [14]), then 
the S-CSCF shall include it in the message body of the REGISTER request within the <service-info> XML 
element as described in subclause 7.6. For the messages including the 3GPP IMS XML body, the S-CSCF shall 
set the value of the Content-Type header to include the MIME type specified in subclause 7.6; 

h) for initial registration and user-initiated reregistration, the P-Charging- Vector header, which shall contain the 
same icid parameter that the S-CSCF received in the original REGISTER request from the UE; 

i) for initial registration and user-initiated reregistration, a P-Charging-Function- Addresses header, which shall 
contain the values received from the HSS if the message is forwarded within the S-CSCF home network. 
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5.4.2 Subscription and notification 



5.4.2.1 



Subscriptions to S-CSCF events 



5.4.2.1.1 



Subscription to tine event providing registration state 



When an incoming SUBSCRIBE request addressed to S-CSCF arrives containing the Event header with the reg event 
package, the S-CSCF shall: 

1) check if, based on the local policy, the request was generated by a subscriber who is authorised to subscribe to 
the registration state of this particular user. The authorized subscribers include: 

- all public user identities this particular user owns, that the S-CSCF is aware of, and which are not-barred; 

- all the entities identified by the Path header (i.e. the P-CSCF to which this user is attached to); and 

- all the ASs hsted in the initial filter criteria and not belonging to third-party providers. 

NOTE: The S-CSCF finds the identity of the originator of the SUBSCRIBE request in the P-Asserted-Identity 



2) generate a 2xx response acknowledging the SUBSCRIBE request and indicating that the authorised subscription 
was successful as described in RFC 3680 [43]. The S-CSCF shall populate the header fields as follows: 

- an Expires header, set to either the same or a decreased value as the Expires header in SUBSCRIBE request; 
and 

- a Contact header, set to is an identifier generated within the S-CSCF that will help to correlate refreshes for 
the SUBSCRIBE. 

Afterwards the S-CSCF shall perform the procedures for notification about registration state as described in 
subclause 5.4.2.1.2. 

5.4.2.1 .2 Notification about registration state 

For each NOTIFY request on all dialogs which have been estabhshed due to subscription to the reg event package of 
that user, the S-CSCF shall: 

1) set the Request-URl and Route header to the saved route information during subscription; 

2) set the Event header to the "reg" value; 

3) in the body of the NOTIFY request, include as many <registration> elements as many public user identities the 
S-CSCF is aware of the user owns; 

4) set the aor attribute within each <registration> element to one public user identity: 

a) set the <uri> sub-element inside the <contact> sub-element of each <registration> element to the contact 
address provided by the UE; and 

b) if the public user identity: 



I) has been deregistered then: 

- set the state attribute within the <registration> element to "terminated" ; 

- set the state attribute within the <contact> element to "terminated"; and 

set the event attribute within the <contact> element to "deactivated", "expired", "unregistered", 
"rejected" or "probation" according RFC 3680 [43]; or 

II) has been registered then: 

- set the state attribute within the <registration> element to "active"; 



header. 
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- set the state attribute within the <contact> element to "active"; and 

- set the event attribute within the <contact> element to "registered"; or 
III) has been automatically registered: 

- set the state attribute within the <registration> element to "active"; 

- set the state attribute within the <contact> element to "active"; and 
set the event attribute within the <contact> element to "created"; and 

5) set the P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]. 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

EXAMPLE: If sip: user l_publicl @homel.net is registered, the public user identity 

sip:userl_public2@homel.net can automatically be registered. Therefore the entries in the body of 
the NOTIFY request look like: 

<?xml version="1.0"?> 

<reginf o xmlns="urn : ietf :params : xml : ns : reginf o" 
version="0" state="full"> 
<registration aor=" sip : userl_publicl@homel . net " id="as9" 
state="active"> 
<contact id="76" state="active" event="registered"> 

<uri>sip : [5555 : : aaa :bbb : ccc :ddd] </uri> 
</contact> 
</registration> 

<registration aor=" sip : userl_public2@homel . net " id="aslO" 
state="active"> 
<contact id="86" state="active" event="created"> 

<uri>sip : [5555 : : aaa :bbb : ccc :ddd] </uri> 
</ contact> 
</registration> 
</reginf o> 

When sending a final NOTIFY request with all <registration> element(s) having their state attribute set to "terminated" 
(i.e. all public user identities have been deregistered or expired), the S-CSCF shall also terminate the subscription to the 
registration event package by setting the Subscription-State header to the value of "terminated". 

The S-CSCF shall only include the non-barred public user identities in the NOTIFY request. 

5.4.3 General treatment for all dialogs and standalone transactions 
excluding requests terminated by the S-CSCF 

5.4.3.1 Determination of mobile-originated or mobile-terminated case 

Upon receipt of an initial request or a target refresh request or a stand-alone transaction, the S-CSCF shall: 

perform the procedures for the mobile-originating case as described in subclause 5.4.3.2 if the request makes use 
of the information for mobile-originating calls, which was added to the Service-Route header entry of the S- 
CSCF during registration (see subclause 5.4.1.2), e.g. the message is received at a certain port or the topmost 
Route header contains a specific user part or parameter; or, 

perform the procedures for the mobile-terminating case as described in subclause 5.4.3.3 if this information is 
not used by the request. 

5.4.3.2 Requests initiated by the served user 

When the S-CSCF receives from the served user an initial request for a dialog or a request for a standalone transaction, 
prior to forwarding the request, the S-CSCF shall: 

1) determine whether the request contains a barred public user identity in the P-Asserted-ldentity header field of the 
request or not. In case the said header field contains a barred public user identity for the user, then the S-CSCF 
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shall reject the request by generating a 403 (Forbidden) response. The response may include a Warning header 
containing the warn-code 399. Otherwise, continue with the rest of the steps; 

NOTE 1: If the P-Asserted-Identity header field contains a barred pubhc user identity, then the message has been 
received, either directly or indirectly, from a non-compliant entity which should have had generated the 
content with a non-barred public user identity. 

2) remove its own SIP URI from the topmost Route header; 

3) check if an original dialog identifier that the S-CSCF previously placed in a Route header is present in the 
topmost Route header of the incoming request. If present, it indicates an association with an existing dialog, the 
request has been sent from an AS in response to a previously sent request; 

4) check whether the initial request matches the next unexecuted initial filter criteria based on a pubhc user identity 
in the P-Asserted-Identity header in the priority order as described in 3GPP TS 23.218 [5], and if it does, the S- 
CSCF shall: 

a) insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI 
populated as specified in the subclause 5.4.3.4; and 

b) if the AS is located outside the trust domain then the S-CSCF shall remove the P-Access-Network-Info 
header field and its values in the request; if the AS is located within the trust domain, then the S-CSCF shall 
retain the P- Access-Network-Info header field and its values in the request that is forwarded to the AS; 

NOTE 2: Depending on the result of processing the filter criteria the S-CSCF might contact one or more AS(s) 
before processing the outgoing Request URI. 

5) if there is no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in the P- 
Charging- Vector header. Optionally, the S-CSCF may generate a new, globally unique icid and insert the new 
value in the icid parameter of the P-Charging-Vector header when forwarding the message. If the S-CSCF 
creates a new icid, then it is responsible for maintaining the two icid values in the subsequent messaging; 

6) if there is no original dialog identifier present in the topmost Route header of the incoming request insert an orig- 
ioi parameter into the P-Charging-Vector header. The S-CSCF shall set the orig-ioi parameter to a value that 
identifies the sending network. The S-CSCF shall not include the term-ioi parameter; 

7) if there is no original dialog identifier present in the topmost Route header of the incoming request insert a P- 
Charging-Function- Addresses header populated with values received from the HSS if the message is forwarded 
within the S-CSCF home network, including towards AS; 

8) if there is no original dialog identifier present in the topmost Route header of the incoming request and if in the 
case where the S-CSCF has knowledge of an associated tel-URI for a SIP URI contained in the received P- 
Asserted-Identity header, add a second P-Asserted-Identity header containing this tel-URI; 

9) if the request is not forwarded to an AS and if the outgoing Request-URI is a TEL URL, the S-CSCF shall 
translate the E.164 address (see RFC 2806 [22]) to a globally routeable SIP URI using an ENUM/DNS 
translation mechanism with the format specified in RFC 2916 [24]. Databases aspects of ENUM are outside the 
scope of the present document. If this translation fails, the request may be forwarded to a BGCF or any other 
appropriate entity (e.g a MRFC to play an announcement) in the originator's home network or the S-CSCF may 
send an appropriate SIP response to the originator; 

10) determine the destination address (e.g. DNS access) using the URI placed in the topmost Route header if present, 
otherwise based on the Request-URI; 

1 l)if network hiding is needed due to local policy, put the address of the I-CSCF(THIG) to the topmost route 
header; 

12) in case of an initial request for a dialog the S-CSCF shall create a Record-Route header containing its own SIP 
URI; 

13) if the destination user (Request-URI) lies outside of the trust domain of the S-CSCF, remove the P- Access- 
Network-Info header, prior to forwarding the message; 

14) route the request based on SIP routeing procedures; and 
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15) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed. 

When the S-CSCF receives any response to the above request, the S-CSCF may: 

1) apply any privacy required by RFC 3323 [33] to the P-Asserted-Identity header. 

NOTE 3: This header would normally only be expected in Ixx or 2xx responses. 

NOTE 4: The optional procedure above is in addition to any procedure for the application of privacy at the edge of 
the trust domain specified by RFC 3323 [33]. 

When the S-CSCF receives any response to the above request containing a term-ioi parameter, the S-CSCF shall store 
the value of the received term-ioi parameter received in the P-Charging- Vector header, if present. The term-ioi 
parameter identifies the sending network of the response message. The term-ioi parameter and the orig-ioi parameter 
shall only be retained in the P-Charging- Vector header if the next hop is to an AS. 

When the S-CSCF receives a Ixx or 2xx response to the initial request for a dialog, if the response corresponds to an 
INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in the response in order to be 
able to release the session if needed. 

When the S-CSCF receives from the served user a target refresh request for a dialog, prior to forwarding the request the 
S-CSCF shall: 

1) remove its own URI from the topmost Route header; 

2) create a Record-Route header containing its own SIP URI; 

3) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed; 

4) in case the request is routed towards the destination user (Request-URI)or is routed to an AS located outside the 
trust domain, remove the P- Access-Network-Info header; and 

5) route the request based on the topmost Route header. 

When the S-CSCF receives a Ixx or 2xx response to the target refresh request for a dialog, if the response corresponds 
to an INVITE request, the S-CSCF shall save the Contact and Record-Route header field values in the response such 
that the S-CSCF is able to release the session if needed. 

When the S-CSCF receives from the served user a subsequent request other than a target refresh request for a dialog, 
prior to forwarding the request the S-CSCF shall: 

1) remove its own URI from the topmost Route header; 

2) in case the request is routed towards the destination user (Request-URI)or is routed to an AS located outside the 
trust domain, remove the P-access-network-info header; and 

3) route the request based on the topmost Route header. 

5.4.3.3 Requests terminated at the served user 

When the S-CSCF receives, destined for a registered served user, an initial request for a dialog or a request for a 
standalone transaction, prior to forwarding the request, the S-CSCF shall: 

1) determine whether the request contains a barred public user identity in the Request-URI of the request or not. In 
case the Request URI contains a barred public user identity for the user, then the S-CSCF shall reject the request 
by generating a 404 (Not Foimd) response. Otherwise, continue with the rest of the steps; 

2) remove its own URI from the topmost Route header; 

3) check if an original dialog identifier that the S-CSCF previously placed in a Route header is present in the 
topmost Route header of the incoming request. 

If present, it indicates an association with an existing dialog, the request has been sent from an AS in 
response to a previously sent request. 
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If not present, it indicates that the request is visiting the S-CSCF for the first time, and in this case the S- 
CSCF shall save the Request-URI from the request; 

4) check whether the initial request matches the next unexecuted initial filter criteria in the priority order and apply 
the filter criteria on the SIP method as described in 3GPP TS 23.218 [5] subclause 6.5. If there is a match, then 
insert the AS URI to be contacted into the Route header as the topmost entry followed by its own URI populated 

as specified in the subclause 5.4.3.4; 

NOTE 1: Depending on the result of the previous process, the S-CSCF may contact one or more AS(s) before 
processing the outgoing Request-URI. 

5) if there is no original dialog identifier present in the topmost Route header of the incoming request insert a P- 
Charging-Function- Addresses header field, if not present, populated with values received from the HSS if the 
message is forwarded within the S-CSCF home network, including towards AS; 

6) if there is no original dialog identifier present in the topmost Route header of the incoming request store the 
value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in the P- 
Charging- Vector header; 

7) if there is no original dialog identifier present in the topmost Route header of the incoming store the value of the 
orig-ioi parameter received in the P-Charging- Vector header, if present. The orig-ioi parameter identifies the 
sending network of the request message. The orig-ioi parameter shall only be retained in the P-Charging- Vector 
header if the next hop is to an AS; 

8) check whether the Request-URI equals to the saved value of the Request-URI. If there is no match, then: 

a) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in 
the request such that the S-CSCF is able to release the session if needed; and 

b) forward the request based on the Request-URI and skip the following steps; 
If there is a match, then continue with the further steps; 

9) in case there are no Route headers in the request, then determine, from the destination public user identity, the 
list of preloaded routes saved during registration or re-registration, as described in subclause 5.4.1.2. 
Furthermore, the S-CSCF shall: 

a) build the Route header field with the values determined in the previous step; 

b) determine, from the destination public user identity, the saved Contact URI where the user is reachable saved 
at registration or reregistration, as described in subclause 5.4.1.2; 

c) build a Request-URI with the contents of the saved Contact URI determined in the previous step; and 

d) insert a P-Called-Party-ID SIP header field including the Request-URI received in the INVITE; 

10) if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed; 

11) optionally, apply any privacy required by RFC 3323 [33] to the P-Asserted-Identity header; and 

NOTE 2: The optional procedure above is in addition to any procedure for the application of privacy at the edge of 
the trust domain specified by RFC 3323 [33]. 

12) forward the request based on the topmost Route header. 

When the S-CSCF receives, destined for an unregistered user, an initial request for a dialog or a request for a standalone 

transaction, the S-CSCF shall: 

1) if the S-CSCF does not have the user profile, then initiate the S-CSCF Registration/deregistration notification 
with the purpose of downloading the relevant user profile (i.e. for unregistered user) and informing the HSS that 
the user is unregistered, but this S-CSCF will assess triggering of services for the unregistered user, as described 
in 3GPP TS 29.228 [14]; 
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2) execute the procedures described in the steps 1, 2 and 3 in the above paragraph (when the S-CSCF receives, 
destined for the registered served user, an initial request for a dialog or a request for a standalone transaction); 
and 

3) execute the procedure described in step 4, 5, 6, 7, 8,9, 11 and 12 in the above paragraph (when the S-CSCF 
receives, destined for the registered served user, an initial request for a dialog or a request for a standalone 
transaction). 

In case that no AS needs to be contacted, then S-CSCF shall return an appropriate imsuccessful SIP response. 
This response may be a 480 (Temporarily unavailable) and terminate these procedures. 

When the S-CSCF receives a Ixx or 2xx response to the initial request for a dialog (whether the user is registered or 
not), it shall: 

1) if the response corresponds to an INVITE request, save the Contact and Record-Route header field values in the 
response such that the S-CSCF is able to release the session if needed; 

2) insert an term-ioi parameter in the P-Charging- Vector header of the outgoing response. The S-CSCF shall set the 
term-ioi parameter to a value that identifies the sending network of the response and the orig-ioi parameter is set 
to the previously received value of orig-ioi; 

3) in the case where the S-CSCF has knowledge of an associated tel-URL for a SIP URl contained in the received 
P-Asserted-Identity header, the S-CSCF shall add a second P-Asserted-Identity header containing this tel-URL; 
and 

4) in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P- 
Access-Network-lnfo header; otherwise, the S-CSCF shall remove the P-Access-Network-lnfo header. 

When the S-CSCF receives a response to a request for a standalone transaction (whether the user is registered or not), in 
the case where the S-CSCF has knowledge of an associated tel-URL for a SIP URI contained in the received P- 
Asserted-Identity header, the S-CSCF shall add a second P-Asserted-Identity header containing this tel-URL. In case 
the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P-Access- 
Network-Info header; otherwise, the S-CSCF shall remove the P-Access-Network-Info header. 

When the S-CSCF receives the 200 (OK) response for a standalone transaction request, the S-CSCF shall: 

1) insert a P-Charging-Function- Addresses header populated with values received from the HSS if the message is 
forwarded within the S-CSCF home network, including towards an AS; and 

2) insert a term-ioi parameter in the P-Charging- Vector header of the outgoing response. The S-CSCF shall set the 
term-ioi parameter to a value that identifies the sending network of the response and the orig-ioi parameter is set 
to the previously received value of orig-ioi. 

When the S-CSCF receives, destined for a served user, a target refresh request for a dialog, prior to forwarding the 
request, the S-CSCF shall: 

1) remove its own URl from the topmost Route header; 

2) if the request is an INVITE request, save the Contact, Cseq and Record-Route header field values received in the 
request such that the S-CSCF is able to release the session if needed; 

3) create a Record-Route header containing its own SIP URI; and 

4) forward the request based on the topmost Route header. 

When the S-CSCF receives a Ixx or 2xx response to the target refresh request for a dialog (whether the user is 
registered or not), the S-CSCF shall: 

1) if the response corresponds to an INVITE request, save the Record-Route and Contact header field values in the 
response such that the S-CSCF is able to release the session if needed; and 

2) in case the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P- 
Access-Network-Info header; otherwise, the S-CSCF shall remove the P-Access-Network-Info header. 

When the S-CSCF receives, destined for the served user, a subsequent request other than target refresh request for a 
dialog, prior to forwarding the request, the S-CSCF shall: 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



62 



ETSI TS 124 229 V5.11.1 (2005-01) 



1) remove its own URI from the topmost Route header; and 

2) forward the request based on the topmost Route header. 

When the S-CSCF receives a response to a a subsequent request other than target refresh request for a dialog, in case 
the response is forwarded to an AS that is located within the trust domain, the S-CSCF shall retain the P-Access- 
Network-Info header; otherwise, the S-CSCF shall remove the P-Access-Network-Info header. 

5.4.3.4 Original dialog identifier 

The original dialog identifier is an implementation specific token that the S-CSCF encodes into the own S-CSCF URI in 
a Route header, prior to forwarding the request to an AS. This is possible because the S-CSCF is the only entity that 

creates and consumes the value. 

The token identifies the original dialog of the request, so in case an AS acting as a B2BUA changes the dialog, the S- 
CSCF is able to identify the original dialog when the request returns to the S-CSCF. The token can be encoded in 
different ways, such as e.g., a character string in the user-part of the S-CSCF URI, a parameter in the S-CSCF URI or 
port number in the S-CSCF URI. 

The S-CSCF shall ensure that the value chosen is unique so that the S-CSCF may recognize the value when received in 
a subsequent message and make the proper association between related dialogs that pass through an AS. 

5.4.3.5 Void 
5.4.4 Call initiation 

5.4.4.1 Initial INVITE 

Void. 

5.4.4.2 Subsequent requests 

5.4.4.2.1 Mobile-originating case 

When the S-CSCF receives any Ixx or 2xx response, the S-CSCF shall insert a P-Charging-Function- Addresses header 
populated with values received from the HSS if the message is forwarded within the S-CSCF home network, including 
towards AS. 

When the S-CSCF receives the UPDATE request, the S-CSCF shall store the access-network-charging-info parameter 
from the P-Charging- Vector header. The S-CSCF shall retain access-network-charging-info parameter in the P- 
Charging- Vector header when the request is forwarded to an AS. However, the S-CSCF shall not include the access- 
network-charging-info parameter in the P-Charging- Vector header when the UPDATE request is forwarded outside the 
home network of the S-CSCF. 

When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a mobile-originated dialog or standalone transaction, the S-CSCF may insert previously saved values into P- 
Charging-Vector and P-Charging-Function-Addresses headers before forwarding the message within the S-CSCF home 
network, including towards AS. 

5.4.4.2.2 Mobile-terminating case 

When the S-CSCF receives the any Ixx or 2xx response, the S-CSCF shall insert a P-Charging-Function-Addresses 
header populated with values received from the HSS if the message is forwarded within the S-CSCF home network, 
including towards AS. 

When the S-CSCF receives 180 (Ringing) or 200 (OK) (to INVITE) responses, the S-CSCF shall store the access- 
network-charging-info parameter from the P-Charging-Vector header. The S-CSCF shall retain the access-network- 
charging-info parameter in the P-Charging- Vector header when the response is forwarded to an AS. However, the S- 
CSCF shall not include the access-network-charging-info parameter in the P-Charging- Vector header when the response 
is forwarded outside the home network of the S-CSCF. 
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When the S-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a mobile-originated dialog or standalone transaction, the S-CSCF may insert previously saved values into P- 
Charging- Vector and P-Charging-Function- Addresses headers before forwarding the message within the S-CSCF home 
network, including towards AS. 

5.4.5 Call release 

5.4.5.1 S-CSCF-initiated session release 

5.4.5.1 .1 Cancellation of a session currently being established 

Upon receipt of an network internal indication to release a session which is currently being estabhshed, the S-CSCF 
shall cancel the related dialogs by sending the CANCEL request according to the procedures described in 
RFC 3261 [26]. 

5.4.5.1 .2 Release of an existing session 

Upon receipt of a network intemal indication to release an existing multimedia session, the S-CSCF shall: 

1) generate a first BYE request for the called user based on the information saved for the related dialog, including: 

- a Request-URI, set to the stored Contact header provided by the called user; 

- a To header, set to the To header value as received in the 200 OK response for the initial INVITE request; 

- a From header, set to the From header value as received in the initial INVITE request; 

a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

- a CSeq header, set to the CSeq value that was stored for the direction from the calling to the called user, 
incremented by one; 

- a Route header, set to the routeing information towards the called user as stored for the dialog; 

further headers, based on local policy or the requested session release reason. 

2) generate a second BYE request for the calling user based on the information saved for the related dialog, 
including: 

- a Request-URI, set to the stored Contact header provided by the calling user; 

a To header, set to the From header value as received in the initial INVITE request; 

- a From header, set to the To header value as received in the 200 OK response for the initial INVITE request; 

- a Call-ID header, set to the Call-Id header value as received in the initial INVITE request; 

a CSeq header, set to the CSeq value that was stored for the direction from the called to the calling user, 
incremented by one - if no CSeq value was stored for that session it shall generate and apply a random 
number within the vaUd range for CSeqs; 

- a Route header, set to the routeing information towards the calling user as stored for the dialog; 
further headers, based on local policy or the requested session release reason. 

3) if the S-CSCF serves the calling user, treat the first BYE request as if received directly from the calling user, i.e. 
send it to internal service control and based on the outcome further on towards the called user; 

4) if the S-CSCF serves the calling user, send the second BYE request directly to the calling user. 

5) if the S-CSCF serves the called user, send the first BYE request directly to the called user; 

6) if the S-CSCF serves the called user, treat the second BYE request as if received directly from the called user, 
i.e. shall send it to intemal service control and based on the outcome further on towards to the calling user. 
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Upon receipt of the 2xx responses for both BYE requests, the S-CSCF shall release all information related to the dialog 
and the related multimedia session. 

5.4.5.1 .2A Release of the existing dialogs due to registration expiration 

When the registration lifetime of the only public user identity currently registered with its associated set of implicitly 
registered public user identities (i.e. no other is registered) expires while there are still active multimedia sessions 
belonging to the served user, the S-CSCF shall release each multimedia session belonging to the served user by 
applying the steps listed in the subclause 5.4.5.1.2. 

5.4.5.1.3 Abnormal cases 

Upon receipt of a request on a dialog for which the S-CSCF initiated session release, the S-CSCF shall terminate the 
received request and answer it with a 481 (Call/Transaction Does Not Exist) response. 

5.4.5.2 Session release initiated by any otiier entity 

Upon receipt of a 2xx response for a BYE request matching an existing dialog, the S-CSCF shall delete all the stored 
information related to the dialog. 

5.4.6 Call-related requests 
5.4.6.1 RelNVITE 

5.4.6.1 .1 Determination of served user 
Void. 

5.4.6.1 .2 Mobile-originating case 

For a relNVITE request from the UE, when the S-CSCF receives the UPDATE request, the S-CSCF shall store the 
updated access-network-charging-info parameter from P-Charging- Vector header. The S-CSCF shall retain the access- 
network-charging-info parameter in the P-Charging- Vector header when the request is forwarded to an AS. However, 
the S-CSCF shall not include the access-network-charging-info parameter in the P-Charging-Vector header when the 
UPDATE request is forwarded outside the home network of the S-CSCF. 

For a relNVITE request from the UE, if the request is to be forwarded to an AS that is located within the trust domain, 
the S-CSCF shall retain the P- Access-Network-Info header; otherwise, the S-CSCF shall remove the P- Access- 
Network-Info header. 

5.4.6.1 .3 Mobile-terminating case 

For a relNVITE request destined towards the UE, when the S-CSCF receives the 200 (OK) response (to the INVITE), 
the S-CSCF shall store the updated access-network-charging-info parameter from the P-Charging- Vector header. The S- 
CSCF shall retain the access-network-charging-info parameter in the P-Charging- Vector header when the response is 
forwarded to the AS. However, the S-CSCF shall include the access-network-charging-info parameter in the P- 
Charging- Vector header when the 200 (OK) response is forwarded outside the home network of the S-CSCF. 

For any SIP response to an INVITE request, if the response is to be forwarded to an AS that is located within the trust 
domain, the S-CSCF shall retain the P-Access-Network-Info header; otherwise, the S-CSCF shall remove the P-Access- 
Network-Info header. 
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5.4.7 Void 

5.5 Procedures at the MGCF 

5.5.1 General 

The MGCF, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to 
be known by peer-to-peer arrangements within the IM CN subsystem. Therefore table A.4/1 and dependencies on that 
major capability shall not apply. 

The use of the Path and Service-Route headers shall not be supported by the MGCF. 

When the MGCF sends any request or response related to a dialog or standalone transaction, the MGCF may insert 
previously saved values into P-Charging- Vector and P-Charging-Function- Addresses headers before sending the 
message. 

5.5.2 Subscription and notification 

Void. 

5.5.3 Call initiation 
5.5.3.1 Initial INVITE 

5.5.3.1 .1 Calls originated from circuit-switched networks 

When the MGCF receives an indication of an incoming call from a circuit-switched network, the MGCF shall: 

- generate and send an INVITE request to I-CSCF: 

- set the Request-URI to the "tel" format using an E.164 address; 

- set the Supported header to " lOOrel" (see RFC 33 12 [30]); 

- include an P-Asserted-Identity header; 

- create a new, globally unique value for the icid parameter and insert it into the P-Charging- Vector header; 
and 

- insert an orig-ioi parameter into the P-Charging- Vector header. The orig-ioi parameter shall be set to a value 
that identifies the sending network in which the MGCF resides and the term-ioi parameter shall not be 
included. 

5.5.3.1 .2 Calls terminating in circuit-switched networks 

When the MGCF receives an initial INVITE request with Supported header indicating "lOOrel", the MGCF shall: 

- send 100 (Trying) response; 

- after a matching codec is found at the MGW, send 183 "Session Progress" response: 

set the Require header to the value of "lOOrel"; 

- store the values received in the P-Charging-Function- Addresses header; 

- store the value of the icid parameter received in the P-Charging- Vector header; and 

insert a term-ioi parameter into the P-Charging-Vector header. The term-ioi parameter shall be set to a value 
that identifies the network in which the MGCF resides. 
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When the MGCF does not find an available matching codec at the MGW for the received initial ESTVITE request, the 
MGCF shall: 

send 503 (Service Unavailable) response if the type of codec was acceptable but none were available; or 

- send 488 (Not Acceptable Here) response if the type of codec was not supported, and may include SDP in the 
message body to indicate the codecs supported by the MGCF/MGW. 

5.5.3.2 Subsequent requests 

5.5.3.2.1 Calls originating in circuit-switched networks 
When the MGCF receives 183 response to an INVITE request, the MGCF shall: 

- store the values received in the P-Charging-Function- Addresses header. 

When the MGCF receives 200 (OK) response to a PRACK request and notification that bearer setup is complete, the 
MGCF shall: 

- send an UPDATE request. 

5.5.3.2.2 Calls terminating in circuit-switched networks 

When the MGCF receives an indication of a ringing for the called party of outgoing call to a circuit-switched network, 
the MGCF shall: 

- send 180 Ringing to the UE. 

When the MGCF receives an indication of answer for the called party of outgoing call to a circuit-switched network, the 
MGCF shall: 

- send 200 OK to the UE, including an P-Asserted-Identity header. 

5.5.4 Call release 

5.5.4.1 Call release initiated by a circuit-switched network 

When the MGCF receives an indication of call release from a circuit- switched network, the MGCF shall: 

- send a BYE request to the UE. 

5.5.4.2 IM CN subsystem initiated call release 

NOTE: The release of a call towards the circuit-switched network additionally requires signaling procedures other 
than SIP in the MGCF that are outside the scope of this document. 

5.5.4.3 MGW-initiated call release 

When the MGCF receives an indication from the MGW that the bearer was lost, the MGCF shall: 

- send a BYE request towards the UE; and 

- may include Error-Info header witha pointer to additional information indicating that bearer was lost. 
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5.5.5 Call-related requests 
5.5.5.1 RelNVITE 

5.5.5.1 .1 Calls originating from circuit-switched networks 
Void. 

5.5.5.1 .2 Calls terminating in circuit-switched networks 

When the MGCF receives a relNVITE request for hold/resume operation, the MGCF shall: 

- send 100 (Trying) response; 

- after performing interaction with MGW to hold/resume the media flow, send 200 (OK) response. 

5.5.6 Further initial requests 

When the MGCF responds to an OPTIONS request with a 200 (OK) response, the MGCF may include a message body 
with an indication of the DTMF capabiUties and supported codecs of the MGCF/MGW. 

NOTE: The detailed interface for requesting MGCF/MGW capabihties is not specified in this version of the 
document. Other solutions may be used in the interim. 

5.6 Procedures at the BGCF 

5.6.1 General 

The use of the Path and Service-Route headers shall not be supported by the BGCF. 

When the BGCF receives any request or response (excluding ACK requests and CANCEL requests and responses) 
related to a dialog or standalone transaction, the BGCF may insert previously saved values into P-Charging- Vector and 
P-Charging-Function- Addresses headers before forwarding the message. 

5.6.2 Session initiation transaction 

When the BGCF receives an INVITE request, the BGCF shall forward the request either to an MGCF within its own 
network, or to another network containing an MGCF. The BGCF need not Record-Route the INVITE request. While 
the next entity may be a MGCF acting as a UA, the BGCF shall not apply the procedures of RFC 3323 [33] relating to 
privacy. The BGCF shall store the values received in the P-Charging-Function- Addresses header. The BGCF shall store 
the value of the icid parameter received in the P-Charging- Vector header and retain the icid parameter in the P- 
Charging- Vector header. 

NOTE: The means by which the decision is made to forward to an MGCF or to another network is outside the 
scope of the present document, but may be by means of a lookup to an external database, or may be by 
data held internally to the BGCF. 

5.7 Procedures at the Application Server (AS) 
5.7.1 Common Application Server (AS) procedures 
5.7.1 .1 Notification about registration status 

The AS may support the REGISTER method in order to discover the registration status of the user. If a REGISTER 
request arrives containing information about the user's registration status and the AS supports the REGISTER method, 
the AS shall store the Expires parameter from the request and generate a 200 (OK) response or an appropriate failure 
response. For the success case, the 200 (OK) response shall contain Expires value equal to the value received in the 
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REGISTER request. The AS shall store the values received in P-Charging-Function-Addresses header. Also, the AS 
shall store the values of the icid parameter in the P-Charging-Vector header from the REGISTER request. 

Upon receipt of a third-party REGISTER request, the AS may subscribe to the reg event package for the public user 
identity registered at the users registrar (S-CSCF) as described in RFC 3680 [43]. 

On sending a SUBSCRIBE request, the AS shall populate the header fields as follows: 

a) a Request URI set to the resource to which the AS wants to be subscribed to, i.e. to a SIP URI that contains the 
public user identity of the user that was received in the To header field of the third-party REGISTER request; 

b) a From header field set to the AS' s SIP URI; 

c) a To header field, set to a SIP URI that contains the public user identity of the user that was received in the To 
header field of the third-party REGISTER request; 

d) an Event header set to the "reg" event package; 

e) a P-Asserted-Identity header field set to the SIP URI of the AS; and 

NOTE 1: The S-CSCF expects the SIP URI used in the P-Asserted-Identity header to correspond to the SIP URI, 
which identified this AS in the initial filter criteria of the user to whose registration state the AS 
subscribes to. 



f) a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]. 

Upon receipt of a 2xx response to the SUBSCRIBE request, the AS shall store the information for the so established 
dialog and the expiration time as indicated in the Expires header of the received response. 

NOTE 2: Upon receipt of a NOTIFY request with all <registration> element(s) having their state attribute set to 
"terminated" (i.e. all public user identities are deregistered) and the Subscription-State header set to 
"terminated", the AS considers the subscription to the reg event package terminated, i.e. as if the AS had 
sent a SUBSCRIBE request with an Expires header containing a value of zero. 



5.7.1 .2 Extracting charging correlation information 

When an AS receives an initial request for a dialog or a request (excluding ACK requests and CANCEL requests and 
responses) for a standalone transaction, the AS shall store the values received in the P-Charging- Vector header, e.g. icid 
parameter, and retain the P-Charging-Vector header in the message. The AS shall store the values received in the P- 
Charging-Function-Addresses header and retain the P-Charging-Function-Addresses header in the message. 

When an AS sends any request or response related to a dialog or standalone transaction, the AS may insert previously 
saved values into the P-Charging- Vector and P-Charging-Function-Addresses headers before sending the message. 



5.7.1.3 Access-Network- Info 

The AS may receive in any request or response (excluding ACK requests and CANCEL requests and responses) 
information about the served user access network. This information is contained in the P- Access-Network-Info header. 
The AS can use the header to provide an appropriate service to the user. 



5.7.2 Application Server (AS) acting as terminating UA, or redirect server 

When acting as a terminating UA the AS shall behave as defined for a UE in subclause 5.1.4, with the exceptions 
identified in this subclause. 

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be 
known by peer-to-peer arrangements within the IM CN subsystem. 

An AS acting as redirect server shall propagate any received 3GPP message body in the redirected message. 

When an AS acting as a terminating UA generates a subsequent request that does not relate to an INVITE dialog, the 
AS shall insert a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]. 
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5.7.3 Application Server (AS) acting as originating UA 

When acting as an originating UA the AS shall behave as defined for a UE in subclause 5.1.3, with the exceptions 
identified in this subclause. 

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be 
known by peer-to-peer arrangements within the IM CN subsystem. 

When an AS acting as an originating UA generates an initial request for a dialog or a request for a standalone 
transaction, the AS shall insert a P-Charging-Vector header with the icid parameter populated as specified in 
3GPP TS 32.225 [17]. The AS may retrieve CCF and/or ECF adresses from HSS on Sh interface. 

When an AS acting as an originating UA generates a subsequent request that does not relate to an ESTVITE dialog, the 
AS shall insert a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]. 

The AS shall extract charging function addresses from any P-Charging-Fimction- Addresses header that is received in 
any Ixx or 2xx responses to the requests. 

Furthermore the AS shall insert a Route header pointing to the S-CSCF of the UE on whose behalf the request is 
generated. 

NOTE: The address of the S-CSCF may be obtained either from a previous request terminated by the AS, by 
querying the HSS on the Sh interface or from static configuration. 

5.7.4 Application Server (AS) acting as a SIP proxy 

When the AS acting as a SIP proxy receives a request from the S-CSCF, prior to forwarding the request it shall: 

- remove its own URI from the topmost Route header; and 

- after executing the required services, route the request based on the topmost Route header. 

The AS may modify the SIP requests based on service logic, prior to forwarding the request back to the S-CSCF. 
An AS acting as a SIP proxy shall propagate any received 3GPP message body in the forwarded message. 

5.7.5 Application Server (AS) performing 3rd party call control 

5.7.5.1 General 

The AS performing 3rd party call control acts as a B2BUA. There are two kinds of 3rd party call control: 

- Routeing B2BUA: an AS receives a request from S-CSCF, terminates it and generates a new request, which is 
based on the received request. 

- Initiating B2BUA: an AS initiates two requests, which are logically connected together at the AS. 

The B2BUA AS will internally map the message headers between the two dialogs that it manages. It is responsible for 
correlating the dialog identifiers and will decide when to simply translate a message from one dialog to the other, or 
when to perform other functions. These decisions are specific to each AS and are outside the scope of the present 
document. 

The AS, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be 
known by peer-to-peer arrangements within the IM CN subsystem. 

5.7.5.2 Call initiation 
5.7.5.2.1 Initial INVITE 

When the AS acting as a Routeing B2BUA receives an initial INVITE request from the S-CSCF, the AS shall: 

- remove its own SIP URI from the topmost Route header of the received INVITE request; 
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- perfonn the AS specific functions. See 3GPP TS 23 .21 8 [5] ; 

- if successful, generate and send a new INVITE request to the S-CSCF to establish a new dialog; 

- copy the remaining Route header(s) imchanged from the received INVITE request to the new INVITE request; 

- route the new INVITE request based on the topmost Route header. 

NOTE: The topmost Route header of the received INVITE request will contain the AS's SIP URI. The following 
Route header will contain the SIP URI of the S-CSCF. 

When the AS is acting as an Initiating B2BUA, the AS shall apply the procedures described in subclause 5.7.3 for both 

requests. The AS shall either set the icid parameter in the P-Charging- Vector header to be the same as received or 
different. The AS may retrieve CCF and/or ECF adresses from HSS on Sh interface. 

5.7.5.2.2 Subsequent requests 

Void. 

5.7.5.3 Call release 

5.7.5.4 Call-related requests 

An AS may initiate a call release. See 3GPP TS 23.218 [5] for possible reasons. The AS shall simultaneously send the 
BYE request for both dialogs managed by the B2BUA. 

5.7.5.5 Further initial requests 

When the AS acting as an Initiating B2BUA the AS shall apply the procedures described in subclause 5.7.3 for both 
requests. The AS shall either set the icid parameter in the P-Charging-Vector header to be the same as received or 
different. 

5.7.6 Void 

5.8 Procedures at the MRFC 
5.8.1 General 

Although the MRFC is acting as a UA, it is outside the scope of this specification how the MRFC associated addresses 
are made known to other entities. 



When the MRFC sends any request or response (excluding ACK requests and CANCEL requests and responses) related 
to a dialog or standalone transaction, the MRFC may insert previously saved values into P-Charging-Vector and P- 
Charging-Function-Addresses headers before sending the message. 



5.8.2 Call initiation 



5.8.2.1 Initial INVITE 

5.8.2.1 .1 MRFC-terminating case 

5.8.2.1.1.1 Introduction 

The MRFC shall provide a P-Asserted-Identity header in a response to the initial request for a dialog, or any response 
for a standalone transaction. It is a matter of network pohcy whether the MRFC expresses privacy according to 
RFC 3323 [33] with such responses. 
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When the MRFC receives an initial INVITE request, the MRFC shall store the values received in the P-Charging- 
Vector header, e.g. icid parameter. The MRFC shall store the values received in the P-Charging-Function- Addresses 
header. 

5.8.2.1 .1 .2 Tones and announcements 

The MRFC can receive INVITE requests to set up a session to play tones and announcements. The MRFC acts as 
terminating UA in this case. 

When the MRFC receives an INVITE request with an indicator for a tone or announcement, the MRFC shall: 

- send 100 (Trying) response. 

NOTE: The detailed interfaces for requesting tones and announcements are not specified in this version of the 
document. Other solutions may be used in the interim. 

5.8.2.1 .1 .3 Ad-hoc conferences 

The MRFC can receive INVITE requests to set up an ad-hoc conferencing session (e.g. Multiparty Call) or to add 
parties from the conference. The MRFC acts as terminating UA in this case. 

When the MRFC receives an INVITE request with an indicator to initiate ad hoc conferencing, the MRFC shall: 

- send 100 (Trying) response; and 

after the MRFP indicates that the conference resources are available, send 200 (OK) response with an MRFC 
conference identifier .If the MRFC chooses to send a 183 (Session Progress) response prior to the 200 (OK), then 
the conference identifier may also be included in the 183 (Session F*rogress) response. 

When the MRFC receives an INVITE request with an indicator to add a party to an existing ad hoc conference 
(i.e. MRFC conference identifier), the MRFC shall: 

- send 100 Trying response; and 

after the MRFP indicates that the conferencing request is granted, send 200 OK response with the MRFC 
conference identifier.If the MRFC chooses to send a 183 Session Progress response prior to the 200 OK, then the 
conference identifier may also be included in the 183 Session Progress response. 

NOTE: The detailed interface for requesting ad-hoc conferencing sessions is not specified in this version of the 
document. Other solutions may be used in the interim. 

5.8.2.1.1.4 Transcoding 

The MRFC may receive INVITE requests to set up transcoding between endpoints with incompatible codecs. The 
MRFC acts as terminating UA in this case. 

When the MRFC receives an INVITE request with an indicator for transcoding and a codec is suppUed in SDP, the 
MRFC shall: 

- send 100 (Trying) response; and 

- after the MRFP indicates that the transcoding request is granted, send 200 (OK) response. 

When the MRFC receives an INVITE request with an indicator for transcoding but no SDP, the MRFC shall: 

- send 183 (Session Progress) response with list of codecs supported by the MRFC/MRFP. 

5.8.2.1 .2 M RFC-originating case 

The MRFC shall provide a P-Asserted-Identity header in an initial request for a dialog, or any request for a standalone 
transaction. It is a matter of network pohcy whether the MRFC expresses privacy according to RFC 3323 [33] with 
such requests. 

When an MRFC generates an initial request for a dialog or a request for a standalone transaction, the MRFC shall insert 
a P-Charging- Vector header with the icid parameter populated as specified in 3GPP TS 32.225 [17]. 
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5.8.2.2 Subsequent requests 
5.8.2.2.1 Tones and announcements 

When the MRFC receives an ACK request for a session, this may be considered as an event to direct the MRFP to start 
the playing of a tone or announcement. 

5.8.3 Call release 

5.8.3.1 S-CSCF-initiated call release 
5.8.3.1 .1 Tones and announcements 

When the MRFC receives a BYE request for a session, the MRFC directs the MRFP to stop the playing of a tone or 
announcement. 

5.8.3.2 MRFC-initiated call release 

5.8.3.2.1 Tones and announcements 

When the MRFC has a timed session to play tones and announcements and the time expires, the MRFC shall: 

- send a BYE request towards the UE. 

When the MRFC is informed by the MRFP that tone or announcement resource has been released, the MRFC shall: 

- send a BYE request towards the UE. 

5.8.2.2.2 Transcoding 

When the MRFC receives a PRACK request (in response to the 183 (Session Progress) response) with an indicator for 
transcoding and codec suppUed in SDP, the MRFC shall: 

- after the MRFP indicates that the transcoding request is granted, send 200 (OK) response. 

5.8.4 Call-related requests 
5.8.4.1 RelNVITE 

5.8.4.1 .1 MRFC-terminating case 

5.8.4.1.1.1 Ad-hoc conferences 

The MRFC can receive relNVlTE requests to modify an ad-hoc conferencing session (e.g. Multiparty Call) for 
purposes of floor control and for parties to leave and rejoin the conference. 

When the MRFC receives a relNVITE request, the MRFC shall: 

send 100 (Trying) response; and 

- after the MRFP indicates that the conferencing request is granted, send 200 (OK) response with the MRFC 
conference identifier .If the MRFC chooses to send a 183 (Session Progress) response prior to the 200 OK, then 
the conference identifier may also be included in the 183 (Session Progress) response. 

NOTE: The detailed interface for requesting ad-hoc conferencing sessions is not specified in this version of the 
document. Other solutions may be used in the interim. 
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5.8.4.1 .2 MRFC-originating case 

Void. 

5.8.4.2 REFER 

5.8.4.2.1 MRFC-terminating case 
Void. 

5.8.4.2.2 MRFC-originating case 

Void. 

5.8.4.2.3 REFER initiating a new session 
Void. 

5.8.4.2.4 REFER replacing an existing session 
Void. 

5.8.4.3 INFO 

Void. 

5.8.5 Further initial requests 

When the MRFC responds to an OPTIONS request with a 200 (OK) response, the MRFC may include a message body 
with an indication of the supported tones/announcement packages, DTMF capabilities, supported codecs and 
conferencing options of the MRFC/MRFP. 

NOTE: The detailed interface for requesting MRFC/MRFP capabilities is not specified in this version of the 
document. Other solutions may be used in the interim. 

6 Application usage of SDP 
6.1 Procedures at the UE 

Usage of SDP by the UE: 

1 . In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. 
Hence, the UE shall not encrypt the SDP payloads. 

2. An INVITE request generated by a UE shall contain SDP payload. The SDP payload shall reflect the calling 
user's terminal capabilities and user preferences for the session. The UE shall order the SDP payload with the 
most preferred codec listed first. In addition, the calling user shall indicate the desired QoS for the session, using 
the segmented status type. In an initial INVITE request the UE shall indicate that it mandates local QoS and that 
this precondition is not yet satisfied, i.e. the UE shall include the following preconditions: 

a=des: qos mandatory local sendrecv 

a=curr: qos local none 

3. Providing that the INVITE request received by the UE contains an SDP offer including one or more "m=" media 
descriptions, the first 183 (Session Progress) provisional response that the UE sends, shall contain the answer for 
the SDP received in the INVITE. The said SDP answer shall reflect the called user's terminal capabilities and 
user preferences. 
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4. When the UE sends a 183 (Session Progress) response with SDP payload including one or more "m=" media 
descriptions, it shall request confirmation for the result of the resource reservation at the originating end point. 

5. During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to 
modify the session description. 

6. For "video" and "audio" media types that utihze the RTP/RTCP, the UE shall specify the proposed bandwidth 
for each media stream utiUzing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP. 

If the media line in the SDP indicates the usage of RTP/RTCP, in addition to the "AS" bandwidth modifier in the 
media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth modifier 
and the other with the "RR" bandwidth modifier as described in RFC 3556 [56] to specify the required 
bandwidth allocation for RTCP. 

For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter 
will affect the assigned QoS which is defined in 3GPP TS 29.208 [13]. 

NOTE 1 : In a two-party session where both participants are active, the RTCP receiver reports are not sent, 
therefore, the RR bandwidth modifer will typically get the value of zero. 

7. The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for audio 
media flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 2833 [23]. 

8. The UE shall inspect the SDP contained in any SIP request or response, looking for possible indications of 
grouping of media streams according to RFC 3524 [54] and perform the action outUned in subclause 9.2.5. 

9. If a PDP context is rejected or modified, the UE shall, if the SDP is affected, update the remote SIP entity 
according to RFC 3261 [26] and RFC 3311 [29]. 

10. If the UE builds SDP for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, as 
described in subclause 5.1.3.1, the UE shall include SDP payload containing a subset of the allowed media types, 
codecs and other parameters from the SDP payload of all 488 (Not Acceptable Here) responses related to the 
same session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). The 
UE shall order the codecs in the SDP payload according to the order of the codecs in the SDP payload of the 488 
(Not Acceptable Here) response. 

NOTE 2: The UE may be attempting a session establishment through multiple networks with different policies and 
potentially may need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) 
responses from different CSCF nodes. The UE therefore takes into account the SDP contents of aU the 
488 (Not Acceptable Here) responses received related to the same session establishment when building a 
new INVITE request. 



6.2 Procedures at the P-CSCF 

When the P-CSCF receives any SIP request containing SDP, the P-CSCF shall examine the media parameters in the 
received SDP. If the P-CSCF finds any media parameters which are not allowed on the network by local policy, the P- 
CSCF shall return a 488 (Not Acceptable Here) response containing SDP payload. This SDP payload contains either all 
the media types, codecs and other SDP parameters which are allowed according to the local policy, or, based on 
configuration by the operator of the P-CSCF, a subset of these allowed parameters. This subset may depend on the 
content of the received SIP request. The P-CSCF shall build the SDP payload in the 488 (Not Acceptable Here) 
response in the same manner as a UAS builds the SDP in a 488 (Not Acceptable Here) response as specifed in 
RFC 3261 [26]. The P-CSCF shall order the SDP payload with the most preferred codec hsted first. 

When the P-CSCF receives an initial INVITE request for a terminating session setup or a 183 (Session Progress) 
response to an INVITE request for an originating session setup, the P-CSCF may modify the SDP according to 
RFC 3524 [54] to indicate to the UE that particular media stream(s) is grouped according to a local policy. The policy is 
used to determine whether the P-CSCF will request the UE to keep media stream(s) grouped in different PDP contexts 
and identify the relation between different media streams and PDP contexts (see subclause 9.2.5). 

The P-CSCF shall apply and maintain the same policy within the SDP from the initial request or response containing 
SDP and throughout the complete SIP session. If a media stream is added and grouping apply to the session, the P- 
CSCF shall modify the SDP according to RFC 3524 [54] to indicate to the UE that the added media stream(s) will be 
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grouped into either a new group or into one of the existing groups. The P-CSCF shall not indicate re-grouping of media 

stream(s) within the SDP. 

The P-CSCF shall not apply RFC 3524 [54] to the SDP for additional media stream(s), if grouping of media stream(s) 
was not indicated in the initial INVITE request or 183 (Session Progress) response. 

The P-CSCF may inspect, if present, the "b=RS" and "b=RR" lines in order to find out the bandwidth allocation 
requirements for RTCP. 

6.3 Procedures at the S-CSCF 

When the S-CSCF receives any SIP request containing SDP, the S-CSCF shall examine the media parameters in the 
received SDP. If the S-CSCF finds any media parameters which are not allowed based on either local policy or the 
subscription, the S-CSCF shall return a 488 (Not Acceptable Here) response containing SDP payload. This SDP 
payload contains either all the media types, codecs and other SDP parameters which are allowed according to the local 
policy and users subscription or, based on configuration by the operator of the S-CSCF, a subset of these allowed 
parameters. This subset may depend on the content of the received SIP request. The S-CSCF shall build the SDP 
payload in the 488 (Not Acceptable Here) response in the same manner as a UAS builds the SDP in a 488 (Not 
Acceptable Here) response as specified in RFC 3261 [26]. 

6.4 Procedures at the MGCF 

6.4.1 Calls originating from circuit-switched networks 

The usage of SDP by the MGCF is the same as its usage by the UE, as defined in the subclause 6.1 and A.3.2, with the 
following exception: 

- In an INVITE request generated by a MGCF, the MGCF shall indicate the current status of the precondition. 

When sending an SDP, the MGCF shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" descriptors in the SDP, 
and it shall ignore them when received in the SDP. 

When the MGCF generates and sends an INVITE request for a call originating in a circuit- switched network, the 
MGCF shall: 

- populate the SDP with the codecs supported by the associated MGW (see 3GPP TS 26.235 [10] for the 
supported codecs); and 

- in order to support DTMF, populate the SDP with MIME subtype "telephone-event" as described in 

RFC 2833 [23]. 

When the MGCF receives 183 (Session Progress) response to an INVITE request, the MGCF shall: 

- check that a supported codec has been indicated in the SDP. 

6.4.2 Calls terminating in circuit-switched networks 

The usage of SDP by the MGCF is the same as its usage by the UE, as defined in the subclause 6.1 and A.3.2, with the 
following exception: 

- When the MGCF sends a 183 (Session Progress) response with SDP payload, it shall only request confirmation 
for the result of the resource reservation at the originating end point if there are any remaining unfulfilled 
preconditions. 

When sending an SDP, the MGCF shall not include the "i=", "u=", "e=", "p=", "r=", and "z=" descriptors in the SDP, 
and it shall ignore them when received in the SDP. 

When the MGCF receives an initial INVITE request, the MGCF shall: 

- check for a codec that matches the requested SDP, which may include the MIME subtype "telephone-event" as 
described in RFC 2833 [23]. 
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When the MGCF generates and sends a 183 (Session Progress) response to an initial ESTVITE request, the MGCF shall: 

- set SDP indicating the selected codec, which may include the MIME subtype "telephone-event" as described in 
RFC 2833 [23]. 

6.5 Procedures at the MRFC 

Void. 

6.6 Procedures at the AS 

Since an AS may provide a wide range of different services, procedures for the SDP usage for an AS acting as 
originating UA, terminating UA or third-party call control role are dependent on the service provided to the UA and on 
the capabilities on the remote UA. There is no special requirements regarding the usage of the SDP, except the 
requirements for the SDP capabilities described in the following paragraphs and clause A.3: 

1) Providing that an INVITE request generated by an AS contains SDP payload, the AS has the capability of 
reflecting the originating AS's capabilities, desired QoS and precondition requirements for the session in the SDP 
payload. 

2) When the AS sends a 183 (Session Progress) response with SDP payload including one or more "m=" media 
types, it has the capabihty of requesting confirmation for the result of the resource reservation at the originating 
endpoint. 



7 Extensions within the present document 

7.1 SIP methods defined within the present document 

There are no SIP methods defined within the present document over and above those defined in the referenced IETF 
specifications. 

7.2 SIP headers defined within the present document 
7.2.0 General 

There are no SIP headers defined within the present document over and above those defined in the referenced IETF 
specifications. 
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7.2.1 Void 

7.2.2 Void 

7.2.3 Void 

7.2.4 Void 

7.2.5 Void 

7.2.6 Void 

7.2.7 Void 

7.2.8 Void 

7.2.9 Void 

7.2.10 Void 

7.2A Extensions to SIP lieaders defined witliln tine present document 
7.2A.1 Extension to WWW-authenticate header 
7.2A.1.1 Introduction 

This extension defines a new authentication parameter (auth-param) for the WWW- Authenticate header used in a 401 
(Unauthorized) response to the REGISTER request. For more information, see RFC 2617 [21] subclause 3.2.1. 

7.2A.1.2 Syntax 

The syntax for for auth-param is specified in table 7.4. 

Table 7.4: Syntax of auth-param 

auth-param = 1# ( integrity-key / cipher-key ) 

integrity-key = "ik" EQUAL ik-value 

cipher-key = "ck" EQUAL ck-value 

ik-value = LDQUOT * (HEXDIG) RDQUOT 

ck-value = LDQUOT * (HEXDIG) RDQUOT 



7.2A.1.3 Operation 

This authentication parameter will be used in a 401 (Unauthorized) response in the WWW-authenticate header during 
UE authentication procedure as specified in subclause 5.4.1. 

The S-CSCF appends the integrity-key parameter (directive) to the WWW. -Authenticate header in a 401 
(Unauthorized) response. The P-CSCF stores the integrity-key value and removes the integrity-key parameter from the 
header prior to forwarding the response to the UE. 
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The S-CSCF appends the cipher-key parameter (directive) to the WWW -Authenticate header in a 401 (Unauthorized) 
response. The P-CSCF removes the cipher-key parameter from the header prior to forwarding the response to the UE. In 
the case ciphering is used, the P-CSCF stores the cipher-key value. 

7.2A.2 Extension to Authorization lieader 

7.2A.2.1 Introduction 

The integrity-protected authentication parameter (auth-param) is an extension parameter defined for the Authorization 
header used in REGISTER requests. For more information, see RFC 2617 [21] subclause 3.2.2. 

7.2A.2.2 Syntax 

The syntax for for auth-param is specified in table 7.5. 

Table 7.5: Syntax of auth-param 



integrity-protected = "integrity-protected" EQUAL ("yes" / "no") 



7.2A.2.3 Operation 

This authentication parameter is inserted by the P-CSCF in all the REGISTER requests received from the UE. The 

value of the "integrity protected" field in the auth-param parameter is set as specified in subclause 5.2.2. This 
information is used by S-CSCF to decide whether to challenge the REGISTER request or not, as specified in 
subclause 5.4.1. 

7.2A.3 Tokenized-by parameter definition (various lieaders) 
7.2A.3.1 Introduction 

The tokenized-by parameter is an extension parameter appended to encrypted entries in various SIP headers as defined 
in subclause 5.3.3.1. 

7.2A.3.2 Syntax 

The syntax for the tokenized-by parameter is specified in table 7.6: 

Table 7.6: Syntax of tokenized-by-param 



uri-parameter = transport-param / user-param / method-param 

/ ttl-param / maddr-param / Ir-param / tokenized-by-param / other-param 

tokenized-by-param = "tokenized-by" EQUAL hostname 



The BNF for uri-parameter is taken from IETF RFC 3261 [26] and modified accordingly. 

7.2A.3.3 Operation 

The tokenized-by parameter is appended by I-CSCF(THIG) after all encrypted strings within SIP headers when network 
configuration hiding is active. The value of the parameter is the domain name of the network which encrypts the 
information. 
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7.2A.4 P-Access-Network-lnfo header 
7.2A.4.1 Introduction 

The P-Access-Network-Info header is extended to include specific information relating to 3GPP access networks. 

7.2A.4.2 Syntax 

The syntax of the P- Access-Network-Info header is described in RFC 3455 [52]. 

7.2A.4.3 Additional coding rules for P-Access-Network-lnfo header 

In 3GPP systems, there are additional coding rules for the P-Access-Network-Info header: 

If the access type field is equal to "3GPP-GERAN" the access info field shall contain a value for "cgi-3gpp" parameter. 
This value shall be the Cell Global Identity obtained from lower layers of the UE. 

The Cell Global Identity is a concatenation of MCC, MNC, LAC and CI (as described in 3GPP TS 23.003 [3]). The 
value of "cgi-3gpp" parameter is therefore coded as a text string as follows: 

Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length 
code of 16 bits using full hexadecimal representation) and CI (fixed length code of 16 bits using a full hexadecimal 
representation). 

If the acce.s-.s- type field is equal to "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD" or "3GPP-CDMA2000" the access 
info field shall contain a value for "utran-cell-id-3gpp" parameter. This value shall be made up of a concatenation of the 
MCC, MNC, LAC (as described in 3GPP TS 23.003 [3]) and the UMTS Cell Identity (as described in 3GPP TS 25.331 
|9A|), obtained from lower layers of the UE, and is coded as a text string as follows: 

Starting with the most significant bit, MCC (3 digits), MNC (2 or 3 digits depending on MCC value), LAC (fixed length 
code of 16 bits using fuU hexadecimal representation) and UMTS Cell Identity (fixed length code of 28 bits). 

7.2A.5 P-Charging-Vector header 

7.2A.5.1 Introduction 

The P-Charging- Vector header is is extended to include specific charging correlation information needed for IM CN 
subsystem functional entities. 

7.2A.5.2 Syntax 

The P-Charging- Vector header field has the syntax described in RFC 3455 [52]. Table 7.3 describes extensions required 
for 3GPP to that syntax. 

Table 7.3: Syntax of extensions to P-Charging-Vector header 



access-network-charging-inf o = (gprs-charging-inf o / generic-param) 

gprs-charging-inf o = ggsn SEMI auth-token [SEMI pdp-inf o-hierarchy ] * (SEMI extension-param) 
ggsn = "ggsn" EQUAL gen-value 

pdp-inf o-hierarchy = "pdp-info" EQUAL LDQUOT pdp-info * (COMMA pdp-info) RDQUOT 

pdp-info = pdp-item SEMI pdp-sig SEMI gcid [SEMI flow-id] 

pdp-item = "pdp-item" EQUAL DIGIT 

pdp-sig = "pdp-sig" EQUAL ("yes" / "no") 

gcid = "gcid" EQUAL 1*HEXDIG 

auth-token = "auth-token" EQUAL 1*HEXDIG 

flow-id = "flow-id" EQUAL "(" "{" 1*DIGIT COMMA 1*DIGIT "}" * (COMMA "{" 1*DIGIT COMMA 1*DIGIT 
II I II J II J II 

extension-param = token [EQUAL token] 
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The access-network-charging-info parameter is an instance of generic-param from the current charge-params 

component of P-Charging-Vector header. 

The access-network-charging-info parameter includes alternative definitions for different types access networks. 

GPRS is the initially supported access network (gprs-charging-info parameter). For GPRS there are the following 
components to track: GGSN address (ggsn parameter), media authorization token (auth token parameter), and a pdp- 
info parameters that contains the information for one or more PDP contexts. The pdp-info contains one or more pdp- 
item values followed by a collection of parameters (pdp-sig, gcid, and flow-id). The value of the pdp-item is a unique 
number that identifies each of the PDP-related charging information within the P-Charging- Vector header. Each PDP 
context has an indicator if it is an IM CN subsystem signalling PDP context (pdp-sig parameter), an associated GPRS 
Charging Identifier (gcid parameter), and a flow identifier (flow-id parameter). The flow-id parameter contains a 
sequence of curly bracket deUmited flow identifier tuples that identify associated m-lines and relative order of port 
numbers in an m-line within the SDP from the SIP signalling to which the PDP context charging information applies. 
For a complete description of the semantics of the flow-id parameter see 3GPP TS 29.207 [12] Annex C. The gcid and 
flow-id parameters are transferred from the GGSN to the P-CSCF (PDF) over the Go interface, see 
3GPPTS 29.207 [12]. 

The gcid value is received in binary format at the P-CSCF (see 3GPP TS 29.207 [12]). The P-CSCF shall encode it in 
hexadecimal format before including it into the gcid parameter. On receipt of this header, a node receiving a gcid shall 
decode from hexadecimal into binary format. 

For a dedicated PDP context for SIP signalling, i.e. no media stream requested for a session, then there is no 
authorisation activity or information exchange over the Go interface. Since there are no GCID, media authorization 
token or flow identifiers in this case, the GCID and media authorization token are set to zero and no flow identifier 
parameters are constructed by the P-CSCF/PDF. 

7.2A.5.3 Operation 

The operation of this header is described in subclauses 5.2, 5.3, 5.4, 5.5, 5.6, 5.7 and 5.8. 

7.3 Option-tags defined within the present document 

There are no option-tags defined within the present document over and above those defined in the referenced IETF 
specifications. 

7.4 Status-codes defined within the present document 

There are no status-codes defined within the present document over and above those defined in the referenced IETF 
specifications. 

7.5 Session description types defined within the present 
document 

There are no session description types defined within the present document over and above those defined in the 
referenced IETF specifications. 

7.6 3GPP IIVI CN subsystem XIVIL body, version 1 
7.6.1 General 

This subclause describes the Document Type Definition that is appUcable for the 3GPP IM CN Subsystem XML body. 

Any SIP User Agent or proxy may insert or remove the 3GPP IM CN subsystem XML body or parts of it, as required, 
in any SIP message. The 3GPP IM CN subsystem XML body shall not be forwarded outside a 3GPP network. 

The associated MIME type with the 3GPP IMS XML body is " application/3 gpp-ims-nxml". 



ETSI 



3GPP TS 24.229 version 5.11 .1 Release 5 81 ETSI TS 1 24 229 V5.1 1 .1 (2005-01 ) 

7.6.2 Document Type Definition 

The Document Type Definition, according to XML syntax definitions, is defined in table 7.7. 

Table 7.7: 3GPP IM CN subsystem XML body, version 1 DTD 



<?xml version="l . 0" ?> 

<! — Draft DTD for the 3GPP IMS XML body. — > 

<!DOCTYPE ims-3gpp [ 

<! — ims-3gpp element: root element — > 

<! ELEMENT ims-3gpp ( 

alternative-service?, service-info?) > 
<!ATTLIST ims-3gpp version CDATA #REQUIRED> 

<! — service-info element: The transparent data received from HSS for AS — > 
<!ELEMENT service-info (#CDATA)> 

<! — alternative-service: alternative-service used in emergency sessions — > 
<! ELEMENT alternative-service (type, reason) > 
<! ELEMENT type (emergency) > 

<! ELEMENT reason (#PCDATA)> 

]> 



7.6.3 DTD description 

This subclause describes the elements of the 3GPP IMS Document Type Definition as defined in table 7.7. 

<ims-3gpp>: This is the root element of the 3GPP IMS XML body. It shall always be present. The version 
described in the present document is 1 . 

<service-info>: the transparent element received from the HSS for a particular trigger point are placed within this 
optional element. 

<alternative-service>: in the present document, the alternative service is used as a response for an attempt to 

establish an emergency session within the IM CN subsystem. The element describes an alternative 
service where the call should success. The alternative service is described by the type of service 
information. A possible reason cause why an alternative service is suggested may be included. 

The <alternative-service> element contains a <type> element that indicates the type of alternative 
service. In the present document, the <type> element contains only the value "emergency". 

The <reason> element contains an explanatory text with the reason why the session setup has been 
redirected. A UE may use this information to give an indication to the user. 

7.7 SIP timers 

The timers defined in RFC 3261 [26] need modification in some cases to accommodate the delays introduced by the air 
interface processing and transmission delays. Table 7.8 shows recommended values for 3GPP. 

Table 7.8 Usts in the first colunm, titied "SIP Timer" the timer names as defined in RFC 3261 [26]. 

The second column, titled "3GPP value to be applied between network elements" lists the values recommended for 
network elements e.g. P-CSCF, S-CSCF, MGCF, when communicating with each other i.e. when no air interface leg is 
included. These values are identical to those recommended by RFC 3261 [26]. 

The third colunm, titled "3GPP value to be appUed at the UE" Usts the values reconmiended for the UE. These are 
modified when compared to RFC 3261 [26] to accommodate the air interface delays. 

The fourth colunm, titled "3GPP value to be applied at the P-CSCF toward a UE" lists the values recommended for the 
P-CSCF when an air interface leg is traversed. These are modified when compared to RFC 3261 [26]. 
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The final column reflects the timer meaning as defined in RFC 3261 [26]. 



Table 7.8: SIP timers 



oi" 1 liner 


oUiKK vaiue TO DB 


ouKK vaiue 10 DG 


oKjirr Value 10 ue appiieu 


n/ieaniiiy 




aDDlied b6tw66n 


aDDlied at the UE 


at the P-CSCF toward a 






network elements 




UE 




T1 


500ms default 


2s default 


2s default 


RTT estimate 


T2 


4s 


16s 


16s 


The maximum retransmit interval for 
non-INVITE requests and INVITE 
responses 


T4 


5s 


17s 


17s 


Maximum duration a message will 
remain in the network 


Timer A 


initially T1 


initially T1 


initially T1 


INVITE request retransmit interval, 
for UDP only 


Timer B 


64*T1 


64*T1 


64*T1 


INVITE transaction timeout timer 


Timer C 


> 3min 


> 3 min 


> 3 min 


proxy INVITE transaction timeout 


Timer D 


> 32s for UDP 


>128s 


>128s 


Wait time for response retransmits 




Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 




Timer E 


initially T1 


initially T1 


initially T1 


non-INVITE request retransmit 
interval, UDP only 


Timer F 


64*T1 


64*T1 


64*T1 


non-INVITE transaction timeout 
timer 


Timer G 


initially T1 


initially T1 


initially T1 


INVITE response retransmit interval 


Timer H 


64*T1 


64*T1 


64*T1 


Wait time for ACK receipt. 


Timer 1 


T4 for UDP 


T4 for UDP 


T4 for UDP 


Wait time for ACK retransmits 




Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 




Timer J 


64*T1 for UDP 


64*T1 for UDP 


84*T1 for UDP 


Wait time for non-INVITE request 




Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 


retransmits 


Timer K 


T4 for UDP 


T4for UDP 


T4 for UDP 


Wait time for response retransmits 




Os for TCP/SCTP 


Os for TCP/SCTP 


Os for TCP/SCTP 





7.8 IM CN subsystem tinners 

Table 7.9 shows recommended values for timers specific to the IM CN subsystem. 



Table 7.9: IM CN subsystem 



Timer 


Value to be 
applied at the UE 


Value to be applied at 
the P-CSCF 


Value to be applied at 
the S-CSCF 


Meaning 


reg-await- 
auth 


Not applicable 


4 minutes 


4 minutes 


The timer is used by the S-CSCF 
during the authentication 
procedure of the UE. For detailed 
usage of the timer see 
subclause 5.4.1 .2. 
The timer is also used by the P- 
CSCF to set the SIP level lifetime 
of the temporary set of securtity 
associations. For detailed usage 
of the timer see 
subclause 5.1 .1 .5. 
The authentication procedure 
may take in the worst case as 
long as 2 times Timer F. The IM 
CN subsystem value for Timer F 
is 1 28 seconds. 
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8 SIP compression 

8.1 SIP compression procedures at the UE 

8.1.1 SIP compression 

The UE shall support SigComp as specified in RFC 3320 [32]. When using SigComp the UE shall send compressed SIP 
messages in accordance with RFC 3486 [55]. The compartment shall finish when the UE is no longer registered. State 
creations and aimouncements shall be allowed only for messages received in a security association. 

The UE shall support the SIP dictionary specified in RFC 3485 [42]. If compression is enabled, the UE shall use the 
dictionary to compress the first message. 

8.1 .2 Compression of SIP requests and responses transmitted to tine P- 
CSCF 

The UE should compress the requests and responses transmitted to the P-CSCF according to subclause 8.1.1. 

NOTE: Compression of SIP messages is an implementation option. However, compression is strongly 
recommended. 

8.1 .3 Decompression of SIP requests and responses received from tlie P- 
CSCF 

The UE shall decompress the compressed requests and responses received from the P-CSCF according to 
subclause 8.1.1. 

If the UE detects a decompression failure at the P-CSCF, the recovery mechanism is implementation specific and this 
may, as an example, include resetting the compartment, changing the algorithm or sending the following message(s) 
without compression. 

8.2 SIP compression procedures at the P-CSCF 

8.2.1 SIP compression 

The P-CSCF shall support SigComp as specified in RFC 3320 [32]. When using SigComp the P-CSCF shall send 

compressed SIP messages in accordance with RFC 3486 [55]. The compartment shall finish when the UE is no longer 
registered. State creations and announcements shall be allowed only for messages received in a security association. 

The P-CSCF shall support the SIP dictionary specified in RFC 3485 [42]. If compression is enabled, the P-CSCF shall 
use the dictionary to compress the first message. 

8.2.2 Compression of SIP requests and responses transmitted to the UE 

The P-CSCF should compress the requests and responses transmitted to the UE according to subclause 8.2.1. 

NOTE: Compression of SIP messages is an implementation option. However, compression is strongly 
reconmiended. 

8.2.3 Decompression of SIP requests and responses received from the 
UE 

The P-CSCF shall decompress the compressed requests and responses received from the UE according to 
subclause 8.2.1. 
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If the P-CSCF detects a decompression failure at the UE, the recovery mechanism is implementation specific and this 
may, as an example, include resetting the compartment, changing the algorithm or sending the following message(s) 
without compression. 



9 GPRS aspects when connected to the IM CN 
subsystem 

9.1 Introduction 

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by GPRS to 
provide packet-mode communication between the UE and the IM CN subsystem. 

Requirements for the UE on the use of these packet-mode services are specified in this clause. Requirements for the 
GGSN in support of this communication are specified in 3GPP TS 29.061 [1 1] and 3GPP TS 29.207 [12]. 

9.2 Procedures at the UE 

9.2.1 PDP context activation and P-CSCF discovery 

Prior to communication with the IM CN subsystem, the UE shall: 

a) perform a GPRS attach procedure; 

b) establish a PDP context used for SIP signalhng according to the APN and GGSN selection criteria described in 
3GPP TS 23.060 [4] and 3GPP TS 27.060 [lOA]. This PDP context shall remain active throughout the period the 

UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration. As 
a result, the PDP context provides the UE with information that makes the UE able to construct an IPv6 address; 

The UE shall choose one of the following options when performing estabhshment of this PDP context: 

I. A dedicated PDP context for SIP signalling: 

The UE shall indicate to the GGSN that this is a PDP context intended to carry IM CN subsystem-related 
signalling only by setting the IM CN Subsystem Signalhng Flag. The UE may also use this PDP context for 
DNS and DHCP signalling according to the static packet filters as described in 3GPP TS 29.061 [11]. The 
UE can also set the Signalhng Indication attribute within the QoS IE; 

II. A general-purpose PDP context: 

The UE may decide to use a general-purpose PDP Context to carry IM CN subsystem-related signaling. The 
UE shall indicate to the GGSN that this is a general-purpose PDP context by not setting the IM CN 
Subsystem Signalling Flag. The UE may carry both signalling and media on the general-piupose PDP 
context. The UE can also set the Signalling Indication attribute within the QoS IE. 

The UE indicates the IM CN Subsystem Signalling Flag to the GGSN within the Protocol Configuration Options 
IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP CONTEXT 
REQUEST message. Upon successful signalling PDP context establishment the UE receives an indication from 
GGSN in the form of IM CN Subsystem Signalling Flag within the Protocol Configuration Options IE. If the 
flag is not received, the UE shall consider the PDP context as a general-purpose PDP context. 

The encoding of the IM CN Subsystem Signalhng Flag within the Protocol Configuration Options IE is 

described in 3GPP TS 24.008 |8|. 

The UE can indicate a request for prioritised handhng over the radio interface by setting the Signalling 
Indication attribute (see 3GPP TS 23.107 [4A]). The general QoS negotiation mechanism and the encoding of 
the Signalling Indication attribute within the QoS IE are described in 3GPP TS 24.008 [8]. 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



85 



ETSI TS 124 229 V5.11.1 (2005-01) 



NOTE: A general-purpose PDP Context may carry both IM CN subsystem signaling and media, in case the media 
does not need to be authorized by Service Based Local Policy mechanisms defined in 
3GPP TS 29.207 [12] and the media stream is not mandated by the P-CSCF to be carried in a separate 
PDP Context. 

c) acquire a P-CSCF address(es). 

The methods for P-CSCF discovery are: 

I. Employ Dynamic Host Configuration Protocol for IPv6 (DHCPv6) RFC 3315 [40], the DHCPv6 options for 
SIP servers RFC 3319 [41] after PDP context activation. 

The UE shall either: 

- in the DHCP query, request a Ust of SIP server domain names of P-CSCF(s) and the list of Domain Name 
Servers (DNS); or 

- request a Ust of SIP server IPv6 addresses of P-CSCF(s). 

II. Transfer P-CSCF address(es) within the PDP context activation procedure. 

The UE shall indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration 
Options IE of the ACTIVATE PDP CONTEXT REQUEST message or ACTIVATE SECONDARY PDP 

CONTEXT REQUEST message. 

If the GGSN provides the UE with a list of P-CSCF IPv6 addresses in the ACTIVATE PDP CONTEXT 
ACCEPT message or ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, the UE shall assume 
that the list is prioritised with the first address within the Protocol Configuration Options IE as the P-CSCF 

address with the highest priority. 

The UE can freely select method I or II for P-CSCF discovery. In case several P-CSCF addresses are provided to 
the UE, the selection of P-CSCF address shall be performed according to the resolution of host name as indicated 
in RFC 3261 [26]. If sufficient information for P-CSCF address selection is not available, selection of the P- 
CSCF address by the UE is implementation specific. 

If the UE is designed to use I above, but receives P-CSCF address(es) according to II, then the UE shall either 
ignore the received address(es), or use the address(es) in accordance with II, and not proceed with the DHCP 
request according to I. 

The UE may request a DNS Server IPv6 address(es) via RFC 33 15 [40] or by the Protocol Configuration 
Options IE when activating a PDP context according to 3GPP TS 27.060 [lOA]. 

The encoding of the request and response for IPv6 address(es) for DNS server(s) and list of P-CSCF address(es) 
within the Protocol Configuration Options IE is described in 3GPP TS 24.008 [8]. 

9.2.1 A Modification of a PDP context used for SIP signalling 

The PDP context shall not be modified from a dedicated PDP context for SIP signalling to a general-purpose PDP 
context or vice versa. The IM CN Subsystem Signalling Flag shall not be set in the Protocol Configuration Options IE 
of the MODIFY PDP CONTEXT REQUEST message. 

The UE shall not indicate the request for a P-CSCF address to the GGSN within the Protocol Configuration Options IE 
of the MODIFY PDP CONTEXT REQUEST message. The UE shall ignore P-CSCF address(es) if received from the 
GGSN in the Protocol Configuration Options IE of the MODIFY PDP CONTEXT RESPONSE message. 

9.2.1 B Re-establishment of the PDP context for signalling 

If the dedicated PDP context for SIP signalling is lost due to e.g. a GPRS routeing area update procedure, the UE shall 
attempt to re-establish the dedicated PDP context for SIP signalhng. If this procedure does not succeed, the UE shall 
deactivate all PDP contexts estabUshed as a result of SIP signalling according to the 3GPP TS 24.008 [8]. 
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9.2.2 Session management procedures 

The existing procedures for session management as described in 3GPP TS 24.008 [8] shall apply while the UE is 
connected to the IM CN subsystem. 

9.2.3 Mobility management procedures 

The existing procedures for mobihty management as described in 3GPP TS 24.008 [8] shall apply while the UE is 
connected to the IM CN subsystem. 

9.2.4 Cell selection and lack of coverage 

The existing mechanisms and criteria for cell selection as described in 3GPP TS 25.304 [9] and 3GPP TS 44.018 [20] 
shall apply while the UE is connected to the IM CN subsystem. 

9.2.5 PDP contexts for media 
9.2.5.1 General requirements 

The UE shall establish different PDP contexts for media streams that belong to different SIP sessions. 

During establishment of a session, the UE establishes data streams(s) for media related to the session. Such data 
stream(s) may result in activation of additional PDP context(s). Such additional PDP context(s) shall be established as 
secondary PDP contexts associated to the PDP context used for signalling. 

When the UE has to allocate bandwidth for RTP and RTCP in a PDP context, the UE shall use the rules outlined in 
3GPPTS 29.208 [13]. 

9.2.5.1 A Activation or modification of PDP contexts for media 

If the UE receives indication within the SDP according to RFC 3524 [54] that media stream(s) belong to group(s), the 
media stream(s) shall be set up on separate PDP contexts according to the indication of grouping. The UE may freely 
group media stteams to PDP context(s) in case no indication of grouping is received from the P-CSCF. 

The UE can receive a media authorization token in the P-Media- Authorization header from the P-CSCF according to 
RFC 3313 [31]. The UE shall, if a media authorization token is received in the P-Media-Authorization header when a 
SIP session is initiated, establish separate PDP context(s) for the media. If a media authorization token is received in 
subsequent messages for the same SIP session, the UE shall: 

use the existing PDP context(s) for media; 

- modify the existing PDP context(s) for media; or 

- establish additional PDP context(s) for media. 

The UE shall ttansparently pass the media authorization token received from the P-CSCF in a response to an INVITE 
request at originating setup or in the INVITE request at terminating setup to the GGSN. The UE shall signal it by 
inserting it within the Traffic Flow Template IE in the ACTIVATE SECONDARY PDP CONTEXT REQUEST 
message or the MODIFY PDP CONTEXT REQUEST message. 

To identify to the GGSN which flow(s) (identified by m-lines within the SDP) that are transferred within a particular 
PDP context, the UE shall set the flow identifier(s) within the Traffic Flow Template IE in the ACTIVATE 
SECONDARY PDP CONTEXT REQUEST message or the MODIFY PDP CONTEXT REQUEST message. Detailed 
description of how the flow identifiers are constructed is provided in 3GPP TS 29.207 [12]. 

Detailed description of how the media authorization token and flow identifiers are carried in the Traffic Flow Template 
IE is provided in 3GPP TS 24.008 [8]. 

If the UE receives several media authorization tokens from the P-CSCF within the same SIP request or response, the 
first instance of the media authorization token shall be sent to the GGSN, and subsequent instances are discarded by the 
UE. 
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The UE shall not re-use a PDP context for other SIP sessions when the session has an associated media authorization 
token. The UE shall deactivate the PDP context when the SIP session that provided the media authorization token is 
terminated. When no media authorization token is used for a SIP session, the UE may reuse the PDP context between 
different SIP sessions. 

The UE shall not include the IM CN Subsystem Signalling Flag when a PDP context for media is established or 
modified. 

9.2.5.2 Special requirements applying to forked responses 

Since the UE does not know that forking has occurred until a second, provisional response arrives, the UE sets up the 
PDP context(s) as required by the initial response received. If a subsequent provisional response is received, different 
alternative actions may be performed depending on the requirements in the SDP answer: 

1) the bearer requirements of the subsequent SDP can be accommodated by the existing PDP context(s). The 

UE performs no activation or modification of PDP contexts. 

2) the subsequent SDP introduces different QoS requirements or additional IP flows. The UE modifies the 
existing PDP context(s), if necessary, according to subclause 9. 2.5.1 A. 

3) the subsequent SDP introduces one or more additional IP flows. The UE establishes additional PDP 
context(s) according to subclause 9.2.5. lA. 

NOTE 1 : When several forked responses are received, the resources requested by the UE is are the "logical OR" of 
the resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE 
does not request more resources than proposed in the original INVITE request. 

NOTE 2: When service-based local policy is applied, the UE receives the same authorization token for all forked 
requests/responses related to the same SIP session. 

When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The UE shall 
release all the unneeded radio/bearer resources. Therefore, upon the reception of a first final 200 (OK) response for the 
INVITE request (in addition to the procedures defined in RFC 3261 [26] subclause 13.2.2.4), the UE shall: 

1) in case PDP context(s) were estabUshed or modified as a consequence of the INVITE request and forked 
provisional responses that are not related to the accepted 200 (OK) response, delete the PDP context(s) or 
modify the delete the PDP context(s) back to their original state. 

9.2.5.3 Unsucessful situations 

One of the Go interface related error codes can be received by the UE in the ACTIVATE SECONDARY PDP 
CONTEXT REJECT message or the MODIFY PDP CONTEXT REJECT message. If the UE receives a Go interface 
related error code, the UE shall either terminate the session or retransmit the message up to three times. The Go 
interface related error codes are further specified in 3GPP TS 29.207 [12]. 
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Annex A (normative): 

Profiles of IETF RFCs for 3GPP usage 

A.1 Profiles 

A. 1 . 1 Relationship to other specifications 

This annex contains a profile to the IETF specifications which are referenced by this specification, and the PICS 
proformas underlying profiles do not add requirements to the specifications they are proformas for. 

This annex provides a profile specification according to both the current IETF specifications for SIP, SDP and other 
protocols (as indicated by the "RFC status" column in the tables in this annex) which are referenced by this 
specification and to the 3GPP specifications using SIP (as indicated by the "Profile status" column in the tables in this 
annex. 

In the "RFC status" column the contents of the referenced specification takes precedence over the contents of the entry 
in the column. 

In the "Profile status" column, there are a number of differences from the "RFC status" column. Where these differences 
occur, these differences take precedence over any requirements of the IETF specifications. Where specification 
concerning these requirements exists in the main body of the present document, the main body of the present document 

takes precedence. 

Where differences occur in the "Profile status" column, the "Profile status" normally gives more strength to a "RFC 
status" and is not be in contradiction with the "RFC status", e.g. it may change an optional "RFC status" to a mandatory 
"Profile status". If the "Profile status" weakens the strength of a "RFC status" then additionally this will be indicated by 
further textual description in the present document. 

For all IETF specifications that are not referenced by this document or that are not mentioned within the 3GPP profile 
of SIP and SDP, the generic rules as defined by RFC 3261 [26] and in addition the rules in clauses 5 and 6 of this 
specification apply, e.g.. 

a proxy which is built in accordance to this specification passes on any unknown method, unknown header field 
or unknown header parameter after applying procedures such as filtering, insertion of P-Asserted-Identity 
header, etc.; 

an UA which is built in accordance to this specification will 

- handle received unknown methods in accordance to the procedures defined in RFC 3261 [26], e.g. respond 
with a 400 (Bad Request) response; and 

- handle unknown header fields and unknown header parameters in accordance to the procedures defined in 
RFC 3261 [26], e.g. respond with a 420 (Bad Extension) if an extension identified by an option tag in the 
Require header of the received request is not supported by the UA. 

A.1 .2 Introduction to methodology within this profile 

This subclause does not reflect dynamic conformance requirements but static ones. In particular, an condition for 
support of a PDU parameter does not reflect requirements about the syntax of the PDU (i.e. the presence of a parameter) 
but the capability of the implementation to support the parameter. 

In the sending direction, the support of a parameter means that the implementation is able to send this parameter (but it 
does not mean that the implementation always sends it). 

In the receiving direction, it means that the implementation supports the whole semantic of the parameter that is 
described in the main part of this specification. 
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As a consequence, PDU parameter tables in this subclause are not the same as the tables describing the syntax of a PDU 
in the reference specification, e.g. RFC 3261 [26] tables 2 and 3. It is not rare to see a parameter which is optional in the 
syntax but mandatory in subclause below. 

The various statii used in this subclause are in accordance with the rules in table A.l. 



Table A.1 : Key to status codes 



Status code 


Status name 


Meaning 


m 


mandatory 


the capability shall be supported. It is a static view of the fact that the 
conformance requirements related to the capability in the reference 
specification are mandatory requirements. This does not mean that a given 
behaviour shall always be observed (this would be a dynamic view), but that it 
shall be observed when the implementation is placed in conditions where the 
conformance requirements from the reference specification compel it to do so. 
For instance, if the support for a parameter in a sent PDU is mandatory, it 
does not mean that it shall always be present, but that it shall be present 
according to the description of the behaviour in the reference specification 
(dynamic conformance requirement). 





optional 


the capability may or may not be supported. It is an implementation choice. 


n/a 


not applicable 


it is impossible to use the capability. No answer in the support column is 
required. 


X 


prohibited (excluded) 


It is not allowed to use the capability. This is more common for a profile. 


c <integer> 


conditional 


the requirement on the capability ("m", "o", "n/a" or "x") depends on the 
support of other optional or conditional items. <integer> is the identifier of 
the conditional expression. 


o.<integer> 


qualified optional 


for mutually exclusive or selectable options from a set. <integer> is the 
identifier of the group of options, and the logic of selection of the options. 


i 


irrelevant 


capability outside the scope of the given specification. Normally, this notation 
should be used in a base specification ICS proforma only for transparent 
parameters in received PDUs. However, it may be useful in other cases, when 
the base specification is in fact based on another standard. 



In the context of this specification the "i" status code mandates that the implementation does not change the content of 
the parameter. It is an implementation option if the implementation acts upon the content of the parameter (e.g. by 
setting filter criteria to known or unknown parts of parameters in order to find out the route a message has to take). 

It must be understood, that this 3GPP SIP profile does not list all parameters which an implementation will treat as 
indicated by the status code "irrelevant". In general an implementation will pass on all unknown messages, header fields 
and header parameters, as long as it can perform its normal behaviour. 

The following additional comments apply to the interpretation of the tables in this Annex. 

NOTE 1: The tables are constructed according to the conventional rules for ICS proformas and profile tables. 

NOTE 2: The notation (either directly or as part of a conditional) of "m" for the sending of a parameter and "i" for 
the receipt of the same parameter, may be taken as indicating that the parameter is passed on 
transparently, i.e. without modification. Where a conditional applies, this behaviour only applies when the 
conditional is met. 

A. 1.3 Roles 



Table A.2: Roles 



Item 


Roles 


Reference 


RFC status 


Profile status 


1 


User agent 


[26] 


0.1 


0.1 


2 


Proxy 


[26] 


0.1 


0.1 


0.1: 


It is mandatory to support exactly one of these items. 






NOTE: 


For the purposes of the present document it has been chosen to keep the specification simple by the tables 
specifying only one role at a time. This does not preclude implementations providing two roles, but an 
entirely separate assessment of the tables shall be made for each role. 
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Table A.3: Roles specific to this profile 



ItGm 


Roles 




111 


Profilp QtfltiiQ 


1 


UE 


5.1 


n/a 


0.1 


2 




o.^ 


n/a 


n 1 
u. 1 


3 


1 PQPP 


O.O 


n/a 


0. 1 


3A 




O.o 


n/a 


C 1 


4 






n/a 


n 1 
U. 1 


5 




O.O 


n/a 


n 1 
U. 1 


6 


MGCF 


o.o 


n/a 


0.1 


7 


AS 


O./ 


n/a 


n -1 
0.1 


7A 




AS acting as terminating UA, or redirect 
server 


5.7.2 


n/a 


c2 


7B 


AS acting as originating UA 


5.7.3 


n/a 


c2 


7C 


AS acting as a SIP proxy 


5.7.4 


n/a 


c2 


7D 


AS performing 3rd party call control 


5.7.5 


n/a 


c2 


8 


MRFC 


5.8 


n/a 


0.1 


c1: 


IF A.3/3 THEN o ELSE x - - l-CSCF. 








c2: 


IF A.3/7 THEN 0.2 ELSE n/a - - AS. 








0.1: 
0.2: 


It is mandatory to support exactly one of these items. 
It is mandatory to support at least one of these items. 






NOTE: 


For the purposes of the present document it has been chosen to keep the specification simple by the tables 
specifying only one role at a time. This does not preclude implementations providing two roles, but an 
entirely separate assessment of the tables shall be made for each role. 



A.2 Profile definition for the Session Initiation Protocol as 
used in the present document 

A.2.1 User agent role 
A.2.1.1 Introduction 

This subclause contains the ICS proforma tables related to the user role. They need to be completed only for UA 
implementations: 

Prerequisite: A.2/1 - - user agent role. 
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A.2.1.2 Major capabilities 



Table A.4: Major capabilities 



Item 


Does the Implementation support 


Reference 


RFC status 


Profile status 




Capabilities withiin main protocol 








1 


client behaviour for registration? 


[26] subclause 10.2 


m 


c3 


2 


registrar? 


[26] subclause 10.3 





c4 


2A 


initiating a session? 


[26] subclause 13 








3 


client behaviour for INVITE requests? 


[26] subclause 13.2 


c18 


c18 


4 


server behaviour for INVITE requests? 


[26] subclause 13.3 


c18 


c18 


5 


session release? 


[26] subclause 15.1 


c18 


c18 


6 


timestamping of requests? 


[26] subclause 8.2.6.1 








7 


authentication between UA and UA? 


[26] subclause 22.2 








8 


authentication between UA and 
registrar? 


[26] subclause 22.2 





n/a 


8A 


authentication between UA and proxy? 


[26] 20.28, 22.3 








9 


server handling of merged requests due 
to forking? 


[26] 8.2.2.2 


m 


m 


10 


client handling of multiple responses 
due to forking? 


[26] 13.2.2.4 


m 


m 


11 


insertion of date in requests and 
responses? 


[26] subclause 20.17 








12 


downloading of alerting information? 


[26] subclause 20.4 










Extensions 








13 


the SIP INFO method? 


[25] 





n/a 


14 


reliability of provisional responses In 
SIP? 


[27] 


c19 


c18 


15 


the REFER method? 


[36] 








16 


integration of resource management 
and SIP? 


[30] 


c19 


c18 


17 


the SIP UPDATE method? 


[29] 


c5 


c18 


19 


SIP extensions for media authorization? 


[311 





c14 


20 


SIP specific event notification? 


[28] 





c13 


21 


the use of NOTIFY to establish a 
dialog? 


[28] 4.2 





n/a 


22 


acting as the notifier of event 
information? 


[28] 


c2 


c15 


23 


acting as the subscriber to event 
information? 


[28] 


c2 


c16 


24 


cpccjnn initifltinn nrotornl pytprr^inn 

oCOOIVJI 1 II IILIClLlwl 1 ^1 VJLVJOkJI CALC7I lOlUI 1 

header field for registering non-adjacent 
contacts? 


[OOJ 


Q 


c6 


25 


private extensions to the Session 
Initiation Protocol (SIP) for network 
asserted identity within trusted 
networks? 


[34] 





m 


26 


a privacy mechanism for the Session 
Initiation Protocol (SIP)? 


[33] 





m 


26A 


request of privacy by the inclusion of a 
Privarv hpaHpr inrlirfltinn finv nrivflpv 

1 1 IVClLry 1 ICClUd II lUILfClLII lU CLi IV l>^l IVCl^^y 

option? 


[33] 


c9 


c11 


26B 


application of privacy based on the 
received Privacy header? 


[33] 


c9 


n/a 


26C 


oassina on of the Privacv header 
transparently? 


[331 


c9 


c12 


26D 


application of the privacy option 
"header" such that those headers which 
cannot be completely expunged of 
identifying information without the 
assistance of intermediaries are 
obscured? 


[33] 5.1 


clO 


c27 


26E 


application of the privacy option 
"session" such that anonymization for 
the session(s) initiated by this message 
occurs? 


[33] 5.2 


clO 


c27 
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26F 


application of tine privacy option "user" 
sucli that user level privacy functions 
are provided by the network? 


[33] 5.3 


clO 


c27 


26G 


application of the privacy option "id" 
such that privacy of the network 
asserted identity Is provided by the 
network? 


[34] 7 


clO 


n/a 


27 


a messaging mechanism for the 
Session Initiation Protocol (SIP)? 


[50] 





c7 


28 


session initiation protocol extension 
header field for service route discovery 
during registration? 


[38] 





c17 


29 


compressing the session initiation 
protocol? 


[55] 





c8 


30 


private header extensions to the 
session initiation protocol for the 3rd- 
Generation Partnership Project 
(3GPP)? 


[52] 





m 


31 


the P-Associated-URI header 

extension? 


[52] 4.1 


c21 


c22 


32 


the P-Called-Party-ID header 
extension? 


[52] 4.2 


c21 


c23 


33 


the P-Visited-Network-ID header 
extension? 


[52] 4.3 


c21 


c24 


34 


the P-Access-Network-lnfo header 

extension? 


[52] 4.4 


c21 


c25 


35 


the P-Charging-Function-Addresses 
header extension? 


[52] 4.5 


c21 


c26 


36 


the P-Charging-Vector header 

extension? 


[52] 4.6 


c21 


c26 


37 


security mechanism agreement for the 
session initiation protocol? 


[48] 





c20 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



93 



ETSI TS 124 229 V5.11.1 (2005-01) 



c2: IF A.4/20 THEN o.1 ELSE n/a - - SIP specific event notification extension. 

c3: IF A.3/1 OR A.3/4 THEN m ELSE n/a - - UE or S-CSCF functional entity. 

c4: IF A.3/4 OR A.3/7 THEN m ELSE n/a - - S-CSCF or AS functional entity. 

c5; IF A. 4/1 6 THEN m ELSE o - - integration of resource management and SIP extension. 

c6: IF A.3/4 OR A.3/1 THEN m ELSE n/a. - - S-CSCF or UE. 

c7: IF A.3/1 OR A.3/4 OR A.3/7A OR A.3/7B OR A.3/7D THEN m ELSE n/a - - UA or S-CSCF or AS acting as 

terminating UA or AS acting as originating UA or AS performing 3"^ party call control.. 
c8: IF A.3/1 THEN m ELSE n/a - - UE behaviour. 

c9: IF A. 4/26 THEN 0.2 ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c10: IF A.4/26B THEN 0.3 ELSE n/a - - application of privacy based on the received Privacy header. 

c1 1 : IF A.3/1 OR A.3/6 THEN o ELSE n/a - - UE or MGCF. 

c12: IF A.3/7D THEN m ELSE n/a - - AS performing 3rd-party call control. 

c1 3: IF A.3/1 OR A.3/4 THEN m ELSE o - - UE behaviour or S-CSCF. 

c14: IF A.3/1 THEN m ELSE IF A.3/2 THEN o ELSE n/a - UE or P-CSCF. 

c15: IF A.4/20 and A.3/4 THEN m ELSE o - SIP specific event notification extensions and S-CSCF. 
c16: IF A.4/20 and (A.3/1 OR A.3/2) THEN m ELSE o - - SIP specific event notification extension and UE or P- 
CSCF. 

c17: IF A.3/1 or A.3/4 THEN m ELSE n/a - - UE or S-CSCF. 
c1 8: IF A.4/2A THEN m ELSE n/a - - initiating sessions. 
c1 9: IF A.4/2A THEN o ELSE n/a - - initiating sessions. 
c20: IF A.3/1 THEN m ELSE n/a - - UE behaviour. 

c21 : IF A.4/30 THEN 0.4 ELSE n/a - - private header extensions to the session initiation protocol for the 3rd- 

Generation Partnership Project (3GPP). 
c22: IF A.4/30 AND (A.3/1 OR A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation 

protocol for the 3rd-Generation Partnership Project (3GPP) and S-CSCF or UA. 
c23: IF A.4/30 AND A.3/1 THEN o ELSE n/a - - private header extensions to the session initiation protocol for 

the 3rd-Generation Partnership Project (3GPP) and UE. 
c24: IF A.4/30 AND A.3/4) THEN m ELSE n/a - - private header extensions to the session initiation protocol for 

the 3rd-Generation Partnership Project (3GPP) and S-CSCF. 
c25: IF A.4/30 AND (A.3/1 OR A.3/4 OR A.3/7A OR A.3/7D) THEN m ELSE n/a - - private header extensions to 

the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and UE, S-CSCF or AS 

acting as terminating UA or AS acting as third-party call controller. 
c26: IF A.4/30 AND (A.3/6 OR A.3/7A OR A.3/7B or A.3/7D) THEN m ELSE n/a - - private header extensions to 

the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and MGCF, AS acting as a 

terminating UA, or AS acting as an originating UA, or AS acting as third-party call controller. 
c27: IF A.3/7D THEN o ELSE x - - AS performing 3rd party call control. 
0.1 : At least one of these capabilities is supported. 
0.2: At least one of these capabilities is supported. 
0.3: At least one of these capabilities is supported. 

0.4: At least one of these capabilities is supported. 
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A.2.1.3 PDUs 



Table A.5: Supported methods 



Item 


PDU 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


ACK request 


[26] 13 


c10 


clO 


[26) 13 


c11 


oil 


2 


BYE request 


[26] 15.1 


c12 


c12 


[26) 15.1 


c12 


c12 


3 


BYE response 


[26] 15.1 


c12 


c12 


[26) 15.1 


c12 


c12 


4 


CANCEL request 


[26] 9 


m 


m 


[26] 9 


m 


m 


5 


CANCEL response 


[26)9 


m 


m 


[26)9 


m 


m 


8 


INVITE request 


[26] 13 


c10 


clO 


[26) 13 


c11 


oil 


9 


INVITE response 


[26] 13 


oil 


oil 


[26) 13 


c10 


clO 


9A 


MESSAGE request 


[50] 4 


c7 


c7 


[50)7 


c7 


c7 


9B 


MESSAGE response 


[50] 4 


c7 


c7 


[50] 7 


c7 


c7 


10 


NOTIFY request 


[28)8.1.2 


c4 


c4 


[28)8.1.2 


c3 


c3 


11 


NOTIFY response 


[28)8.1.2 


c3 


c3 


[28)8.1.2 


c4 


c4 


12 


OPTIONS request 


[26] 1 1 


m 


m 


[26] 1 1 


m 


m 


13 


OPTIONS response 


[26] 1 1 


m 


m 


[26] 1 1 


m 


m 


14 


PRACK request 


[27] 6 


c5 


c5 


[27)6 


c5 


c5 


15 


PRACK response 


[27)6 


c5 


c5 


[27] 6 


c5 


c5 


16 


REFER request 


[36] 3 


c1 


cl 


[36)3 


c1 


cl 


17 


REFER response 


[36)3 


Cl 


cl 


[36)3 


c1 


cl 


18 


REGISTER request 


[26] 10 







[26] 10 


n/a 




19 


REGISTER response 


[26] 10 


n/a 




[26] 10 


m 




20 


SUBSCRIBE request 


[28] 8.1.1 


c3 


c3 


[28] 8.1.1 


c4 


c4 


21 


SUBSCRIBE response 


[28] 8.1.1 


c4 


c4 


[28)8.1.1 


c3 


c3 


22 


UPDATE request 


[30) 6.1 


c6 


c6 


[30) 6.2 


c6 


c6 


23 


UPDATE response 


[30) 6.2 


c6 


c6 


[30) 6.1 


c6 


c6 



cl: 
c3: 
c4: 
c5: 
c6: 
c7: 
ClO 
oil 
c12 



IF A.4/15THEN m ELSE n/a ■ 
IF A.4/23 THEN m ELSE n/a ■ 
IF A.4/22 THEN m ELSE n/a ■ 
IF A.4/14THEN m ELSE n/a - 
IF A.4/17THEN m ELSE n/a ■ 
IF A.4/27 THEN m ELSE n/a ■ 
IFA.4/3 THEN m ELSE n/a - ■ 
IF A.4/4 THEN m ELSE n/a-- 
IFA.4/5 THEN m ELSE n/a - ■ 



- the REFER method extension. 

- recipient for event information. 

- notifier of event information. 

- reliability of provisional responses extension. 

- the SIP update method extension. 

- the SIP MESSAGE method, 
client behaviour for INVITE requests, 
server behaviour for INVITE requests, 
session release. 



Editor's note: Optional status of REGISTER in RFC status is given because RFC states RECOMMENDED (client); 
for the UAS, not statement is made, but it is assumed that this therefore means n/a. 
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A.2.1.4 PDU parameters 
A.2. 1.4.1 Status-codes 



Table A.6: Supported status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


100 (Trying) 


[26] 21.1.1 


n/a 


n/a 


[26] 21.1.1 


m 


m 


2 


180 (Ringing) 


[26] 21.1.2 


c2 


c2 


[26] 21.1.2 


cl 


cl 


3 


181 (Call Is Being 
Forwarded) 


[26] 21.1.3 


c2 


c2 


[26] 21.1.3 


cl 


cl 


4 


182 (Queued) 


[26] 21.1.4 


c2 


c2 


[26] 21.1.4 


cl 


cl 


5 


1 83 (Session Progress) 


[26] 21.1.5 


Cl 


cl 


[26] 21.1.5 


cl 


cl 


6 


200 (OK) 


[26] 21.2.1 






[26] 21.2.1 






7 


202 (Accepted) 


[28] 8.3.1 


c3 


c3 


[28] 8.3.1 


c3 


c3 


8 


300 (Multiple Choices) 


[26] 21.3.1 






[26] 21.3.1 






9 


301 (Moved Permanently) 


[26] 21.3.2 






[26] 21.3.2 






10 


302 (Moved Temporarily) 


[26] 21.3.3 






[26] 21.3.3 






11 


305 (Use Proxy) 


[26] 21.3.4 






[26] 21.3.4 






12 


380 (Alternative Service) 


[26] 21 .3.5 






[26] 21 .3.5 






13 


400 (Bad Request) 


[26] 21.4.1 






[26] 21.4.1 






14 


401 (Unauthorized) 


[26] 21.4.2 






[26] 21 .4.2 






15 


402 (Payment Required) 


[26] 21 .4.3 






[26] 21.4.3 






16 


403 (Forbidden) 


[26] 21 .4.4 






[26] 21 .4.4 






17 


404 (Not Found) 


[26] 21.4.5 






[26] 21.4.5 






18 


405 (Method Not Allowed) 


[26] 21 .4.6 






[26] 21.4.6 






19 


406 (Not Acceptable) 


[26] 21 .4.7 






[26] 21 .4.7 






20 


407 (Proxy Authentication 

Required) 


[26] 21 .4.8 






[26] 21 .4.8 






21 


408 (Request Timeout) 


[26] 21.4.9 






[26] 21.4.9 






22 


410 (Gone) 


[26] 21.4.10 






[26] 21.4.10 






23 


413 (Request Entity Too 
Large) 


[26] 21.4.11 






[26] 21.4.11 






24 


414 (Request-URI Too 
Large) 


[26] 21.4.12 






[26] 21.4.12 






25 


415 (Unsupported Media 
Type) 


[26] 21.4.13 






[26] 21.4.13 






26 


416 (Unsupported URI 

Scheme) 


[26] 21.4.14 






[26] 21.4.14 






27 


420 (Bad Extension) 


[26] 21.4.15 






[26] 21.4.15 






28 


421 (Extension Required) 


[26] 21.4.16 






[26] 21.4.16 






29 


423 (Interval Too Brief) 


[26] 21.4.17 


c4 


c4 


[26] 21.4.17 


m 


m 


30 


480 (Temporarily 
Unavailable) 


[26] 21.4.18 






[26] 21.4.18 






31 


481 (Call/Transaction 
Does Not Exist) 


[26] 21.4.19 






[26] 21.4.19 






32 


482 (Loop Detected) 


[26] 21 .4.20 






[26] 21 .4.20 






33 


483 (Too Many Hops) 


[26] 21.4.21 






[26] 21.4.21 






34 


484 (Address Incomplete) 


[26] 21 .4.22 






[26] 21 .4.22 






35 


485 (Ambiguous) 


[26] 21.4.23 






[26] 21.4.23 






36 


486 (Busy Here) 


[26] 21 .4.24 






[26] 21 .4.24 






37 


487 (Request Terminated) 


[26] 21 .4.25 






[26] 21 .4.25 






38 


488 (Not Acceptable Here) 


[26] 21 .4.26 






[26] 21 .4.26 






39 


489 (Bad Event) 


[28] 7.3.2 


c3 


c3 


[28] 7.3.2 


c3 


c3 


40 


491 (Request Pending) 


[26] 21.4.27 






[26] 21 .4.27 






41 


493 (Undecipherable) 


[26] 21 .4.28 






[26] 21 .4.28 






41 A 


494 (Security Agreement 
Required) 


[48] 2 


c5 


c5 


[48] 2 


c6 


c6 


42 


500 (Internal Server Error) 


[26] 21.5.1 






[26] 21.5.1 






43 


501 (Not Implemented) 


[26] 21.5.2 






[26] 21.5.2 






44 


502 (Bad Gateway) 


[26] 21 .5.3 






[26] 21 .5.3 






45 


503 (Service Unavailable) 


[26] 21.5.4 






[26] 21.5.4 






46 


504 (Server Time-out) 


[26] 21 .5.5 






[26] 21 .5.5 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


47 


505 (Version not 
supported) 


[26] 21.5.6 






[26] 21.5.6 






A Q 


513 (Message Too Large) 


[26] 21.5.7 






[26] 21.5.7 






49 


580 (Precondition Failure) 


[30] 8 






[30] 8 






50 


600 (Busy Everywhere) 


[26] 21 .6.1 






[26] 21 .6.1 






51 


603 (Decline) 


[26] 21.6.2 






[26] 21.6.2 






52 


604 (Does Not Exist 
Anywhere) 


[26] 21 .6.3 






[26] 21 .6.3 






53 


606 (Not Acceptable) 


[26] 21.6.4 






[26] 21.6.4 







c1 : IF A.5/9 THEN m ELSE n/a - - INVITE response. 

c2: IF A.5/9 THEN o ELSE n/a - - INVITE response. 

c3: IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

c4: IF A.5/19 OR A.5/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE response. 

c5: IF A.4/37 AND A. 4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 



and registrar. 

c6: IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 



A.2.1.4.2 ACK method 

Prerequisite A.5/1 - ACK request 



Table A.7: Supported headers within the ACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


3 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


7 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


8 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


9 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


10 


Content-Type 


[26] 20.15 








[26] 20.15 


m 


m 


11 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


12 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


13 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


14 


l\/lax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


15 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


15A 


Privacy 


[33] 4.2 


c6 


n/a 


[33] 4.2 


c6 


n/a 


16 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


17 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


18 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


19 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


20 


Timestamp 


[26] 20.38 


c7 


c7 


[26] 20.38 


m 


m 


21 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


22 


User-Agent 


[26] 20.41 








[26] 20.41 


m 


m 


23 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



cl : IF A.4/20 THEN o ELSE n/a - 

c2: IF A.4/20 THEN m ELSE n/a- 

c3: IF A.4/7 THEN m ELSE n/a - 

c4: IF A.4/11 THEN ELSE n/a - 

c5: IF A.4/8A THEN m ELSE n/a 

c6: IF A.4/26 THEN ELSE n/a - 

c7: IF A.4/6 THEN o ELSE n/a - - 



- SIP specific event notification extension. 

- SIP specific event notification extension, 
authentication between UA and UA. 

- insertion of date in requests and responses. 
■ - authentication between UA and proxy. 

- a privacy mechanism for the Session Initiation Protocol (SIP). 
timestamping of requests. 



Editor's note: Is the following table a suitable way of showing the contents of message bodies. 
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Prerequisite A.5/1 - ACK request 



Table A.8: Supported message bodies within tlie ACK request 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2. 1.4.3 BYE method 

Prerequisite A.5/2 - - BYE request 

Table A.9: Supported headers within the BYE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


IVIax-Fonwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


16 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c9 


clO 


[52] 4.4 


c9 


c11 


16B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c6 


c6 


16C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c13 


c14 


[52] 4.5 


c13 


c14 


16D 


P-Charging-Vector 


[52] 4.6 


c12 


n/a 


[52] 4.6 


c12 


n/a 


16E 


P-Preferred-ldentity 


[34] 9.2 


c6 


X 


[34] 9.2 


n/a 


n/a 


16F 


Privacy 


[33] 4.2 


c7 


n/a 


[33] 4.2 


c7 


c7 


17 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


18 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


19 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


20 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


21 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


21A 


Security-Client 


[48] 2.3.1 


c15 


c15 


[48] 2.3.1 


n/a 


n/a 


21 B 


Security-Verify 


[48] 2.3.1 


CIS 


c16 


[48] 2.3.1 


n/a 


n/a 


22 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


23 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


24 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


25 


User-Agent 


[26] 20.41 








[26] 20.41 








26 


Via 


[26] 20.42 


m 


m 


[20] 20.42 


m 


m 



cl: 
c2: 
c3: 
c4: 
c5: 
c6: 

c7: 

c8: 

c9: 

clO: 

c11: 

c12 
c13 
c14 
c15 
c16 



IF A.4/20 THEN o ELSE n/a - 
IF A.4/20 THEN m ELSE n/a 
IF A.4/7 THEN m ELSE n/a - 
IFA.4/11 THEN ELSE n/a - 
IF A.4/8A THEN m ELSE n/a 
IF A.4/25 THEN o ELSE n/a - 
within trusted networks. 
IF A.4/26 THEN o ELSE n/a - 
IFA.4/6 THEN ELSE n/a - - 
IF A.4/34 THEN o ELSE n/a - 



- SIP specific event notification extension. 

■ - SIP specific event notification extension. 

- authentication between UA and UA. 

- insertion of date in requests and responses. 

- - authentication between UA and proxy. 

- private extensions to the Session Initiation Protocol (SIP) for asserted identity 



- a privacy mechanism for the Session Initiation Protocol (SIP), 
timestamping of requests. 

- the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and AS 
acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note). 

- security mechanism agreement for the session initiation protocol. 



IF A.4/35 THEN o ELSE n/a ■ 
IF A.4/35 THEN m ELSE n/a 
IF A.4/37 THEN o ELSE n/a 
IFA.4/37 THEN m ELSE n/a 



NOTE: Support of this header in this method is dependent on the security mechanism and the security architecture which 

is implemented. Use of this header in this method is not appropriate to the security mechanism defined by 
3GPP TS 33.203 [19]. 
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Prerequisite A.5/2 - - BYE request 



Table A.10: Supported message bodies within tlie BYE request 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/3 - - BYE response 
Prerequisite: A.6/1 - - 100 (Trying) 



Table A.11 : Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


n/a 


n/a 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


n/a 


n/a 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


n/a 


n/a 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


n/a 


n/a 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


n/a 


n/a 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


n/a 


n/a 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


n/a 


n/a 


[26] 20.42 


m 


m 
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Prerequisite A.5/3 - - BYE response 



Table A.12: Supported headers within the BYE response - all remaining status-codes 



Item 


IHeader 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


d. 


Content- Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


P-Access- Netwo rk- 1 nf o 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c6 


10B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


IOC 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


clO 


[52] 4.5 


c9 


clO 


10D 


P-Cliarging-Vector 


[52] 4.6 


c8 


n/a 


[52] 4.6 


c8 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10F 


Privacy 


[33] 4.2 


c4 


n/a 


[33] 4.2 


c4 


c4 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


10H 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









cl : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2; IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
c4: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

clO: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/3 - - BYE response 
Prerequisite: A.6/6 - - 2xx 



Table A.13: Supported headers within the BYE response 



Item 


iHeader 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
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Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.14: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


OB 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/3 - - BYE response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.15: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Table A.16: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Retry-After 


[26] 20.33 








[26] 20.33 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.17: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/19 - - 407 (Proxy Authentication Required) 



Table A.18: Supported headers within the BYE response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


Cl 


cl 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/3 - - BYE response 

Prerequisite A.6/25 - - 415 (Unsupported Media Type) 

Table A.19: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 


At least one of these capabilities is supportec 


. 



Prerequisite A.5/3 - - BYE response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.20: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/3 - - BYE response 

Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.20A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


3 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protoco 
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Prerequisite A.5/3 - - BYE response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 



Table A.21 : Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/3 - - BYE response 



Table A.22: Supported message bodies within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.2.1.4.4 CANCEL method 

Prerequisite A.5/4 - - CANCEL request 



Table A.23: Supported headers within the CANCEL request 



Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



Allow-Events 



[28] 7.2.2 



c1 



c1 



[28] 7.2.2 



c2 



c2 



Authorization 



[26] 20.7 



c3 



c3 



[26] 20.7 



c3 



c3 



Call-ID 



[26] 20.8 



m 



m 



[26] 20.8 



m 



m 



Content-Length 



[26] 20.14 



m 



m 



[26] 20.14 



m 



m 



Cseq 



[26] 20.16 



m 



m 



[26] 20.16 



m 



m 



10 



Date 



[26] 20.17 



c4 



c4 



[26] 20.17 



m 



m 



11 



From 



[26] 20.20 



m 



m 



[26] 20.20 



m 



m 



12 



Max-Forwards 



[26] 20.22 



m 



m 



[26] 20.22 



n/a 



n/a 



14 



Privacy 



[33] 4.2 



c6 



n/a 



[33] 4.2 



c6 



n/a 



16 



Record-Route 



[26] 20.30 



n/a 



n/a 



[26] 20.30 



n/a 



n/a 



18 



Route 



[26] 20.34 



m 



m 



[26] 20.34 



n/a 



n/a 



19 



Supported 



[26] 20.37 



[26] 20.37 



m 



m 



20 



Timestamp 



[26] 20.38 



c8 



c8 



[26] 20.38 



m 



m 



21 



To 



[26] 20.39 



m 



m 



[26] 20.39 



m 



m 



22 



User-Agent 



[26] 20.41 



[26] 20.41 



23 



Via 



[26] 20.42 



m 



m 



[26] 20.42 



m 



m 



c1: IF A.4/20 THEN o ELSE n/a - 

c2: IF A.4/20 THEN m ELSE n/a 

c3: IF A.4/7 THEN m ELSE n/a - 

c4: IF A.4/1 1 THEN o ELSE n/a - 

c6: IF A.4/26 THEN ELSE n/a - 

c8: IF A.4/6 THEN o ELSE n/a - - 



- SIP specific event notification extension. 

- SIP specific event notification extension. 
■ authentication between UA and UA. 

- insertion of date in requests and responses. 

- a privacy mechanism for the Session Initiation Protocol (SIP). 
timestamping of requests. 
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Prerequisite A.5/4 - - CANCEL request 



Table A.24: Supported message bodies within tlie CANCEL request 



item 


iHeader 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/5 - - CANCEL response 



Tabie A.25: Supported lieaders witliin tlie CANCEL response - all status-codes 



Item 


IHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


5A 


Privacy 


[33] 4.2 


c3 


n/a 


[33] 4.2 


c3 


n/a 


6 


TImestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


7 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7A 


User-Agent 


[26] 20.41 








[26] 20.41 








8 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


9 


Warning 


[26] 20.43 


(note) 





[26] 20.43 








c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
c2: IF A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 


NOTE: For a 606 (Not Acceptable Here) response, this status is RECOIVIIVIENDED rather than OPTIONAL. 



Prerequisite A.5/5 - - CANCEL response 
Prerequisite: A.6/6 - - 200 (OK) 

Table A.26: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


2 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/5 - - CANCEL response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.27: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
Status 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/5 - - CANCEL response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 500, 503, 
600, 603 



Table A.28: Supported headers within the CANCEL response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Retry-After 


[26] 20.33 








[26] 20.33 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/5 - - CANCEL response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 

Tabie A.30: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/5 - - CANCEL response 

Table A.31 : Supported message bodies within the CANCEL response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.5 COMET method 

Void 

A.2.1.4.6 INFO method 

Void 

A.2.1.4.7 INVITE method 

Prerequisite A.5/8 - - INVITE request 



Table A.46: Supported headers within the INVITE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


4 


Alert-Info 


[26] 20.4 








[26] 20.4 


Cl 


cl 


5 


Allow 


[26] 20.5, 
[26] 5.1 


(note 1) 





[26] 20.5, 
[26] 5.1 


m 


m 


6 


Allow-Events 


[28] 7.2.2 


c2 


c2 


[28] 7.2.2 


c2 


c2 


8 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


9 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


10 


Call-Info 


[26] 20.9 








[26] 20.9 








11 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


12 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


13 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


14 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


15 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


16 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


17 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


18 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


19 


Expires 


[26] 20.19 








[26] 20.19 








20 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


21 


In-Reply-To 


[26] 20.21 








[26] 20.21 








22 


IVlax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


23 


IVIIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


24 


Organization 


[26] 20.25 








[26] 20.25 








24A 


P-Access-Network-lnfo 


[52] 4.4 


c15 


c16 


[52] 4.4 


c15 


c17 


24B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c7 


c7 


24C 


P-Called-Party-ID 


[52] 4.2 


x 


X 


[52] 4.2 


c13 


c13 


24D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c21 


[52] 4.5 


c20 


c21 


24E 


P-Charging-Vector 


[52] 4.6 


CIS 


c19 


[52] 4.6 


CIS 


c19 


25 


P-Media-Authorization 


[31] 6.1 


n/a 


n/a 


[31] 6.1 


c11 


c12 


25A 


P-Preferred-ldentity 


[34] 9.2 


c7 


c5 


[34] 9.2 


n/a 


n/a 


25B 


P-Visited-Network-ID 


[52] 4.3 


X (note 3) 


X 


[52] 4.3 


c14 


n/a 


26 


Priority 


[26] 20.26 








[26] 20.26 








26A 


Privacy 


[33] 4.2 


c9 


c9 


[33] 4.2 


c9 


c9 


27 


Proxy-Authorization 


[26] 20.28 


c6 


c6 


[26] 20.28 


n/a 


n/a 


28 


Proxy-Require 


[26] 20.29 


(note 2) 


(note 2) 


[26] 20.29 


n/a 


n/a 


29 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


m 


m 


31 


Reply-To 


[26] 20.31 








[26] 20.31 








32 


Require 


[26] 20.32 





m 


[26] 20.32 


m 


m 


33 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


33A 


Security-Client 


[48] 2.3.1 


c22 


c22 


[48] 2.3.1 


n/a 


n/a 


33B 


Security-Verify 


[48] 2.3.1 


c23 


c23 


[48] 2.3.1 


n/a 


n/a 


34 


Subject 


[26] 20.36 








[26] 20.36 








35 


Supported 


[26] 20.37 


c8 


m 


[26] 20.37 


m 


m 


36 


Timestamp 


[26] 20.38 


clO 


clO 


[26] 20.38 


m 


m 


37 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



38 



User-Agent 



[26] 20.41 



[26] 20.41 



39 



Via 



[26] 20.42 



m 



m 



[26] 20.42 



m 



m 



c1: 
c2: 
c3: 
c4: 
c5: 

c6: 
c7: 

c9: 
clO 
c11 
c12 
c13 
c14 
c15 
c16 
c17 

c18 
c19 
c20 
c21 
c22 
c23 
0.1: 



IF A.4/12 THEN m ELSE n/a - - downloading of alerting information. 
IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networl<s. 

IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

timestamping of requests. 

- SIP extensions for media authorization. 
UE. 

- the P-Called-Party-ID extension. 

-the P-Visited-Network-ID extension. 

- the P-Access-Network-lnfo header extension. 

IF A. 4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 4). 
security mechanism agreement for the session initiation protocol. 



IF A.4/6 THEN o ELSE n/a - 
IF A.4/19THEN m ELSE n/a 
IF A.3/1 THEN m ELSE n/a - 
IF A.4/32 THEN o ELSE n/a 
IF A.4/33 THEN o ELSE n/a 
IF A.4/34 THEN o ELSE n/a 



IF A.4/35 THEN o ELSE n/a ■ 
IF A.4/35 THEN m ELSE n/a 
IF A.4/37 THEN o ELSE n/a ■ 
IF A.4/37 THEN m ELSE n/a 



At least one of these shall be supported. 



NOTE 1 : 
NOTE 2: 



NOTE 3: 
NOTE 4: 



The strength of this requirement in RFC 3261 [26] is RECOMMENDED, rather than OPTIONAL. 
No distinction has been made in these tables between first use of a request on a From/To/Call-ID 
combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included 

from a viewpoint of first usage. 

The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 
Support of this header in this method is dependent on the security mechanism and the security architecture 
which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/8 - - INVITE request 

Table A.47: Supported message bodies within the INVITE request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/1 - - 100 (Trying) 



Table A.48: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


n/a 


n/a 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


n/a 


n/a 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


n/a 


n/a 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


n/a 


n/a 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


n/a 


n/a 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


n/a 


n/a 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


n/a 


n/a 


[26] 20.42 


m 


m 



Prerequisite A.5/9 - - INVITE response 



Table A.49: Supported headers within the INVITE response - all remaining status-codes 



llcill 


ncaUcr 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Gall-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1A 


Gall-Info 


[26] 20.9 








[26] 20.9 








2 


Gontent-Dlsposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Gontent-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIME-Verslon 


[26] 20.24 








[26] 20.24 


m 


m 


11 


Organization 


[26] 20.25 








[26] 20.25 








11A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


11B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


11C 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


c11 


c11 


11D 


P-Charglng-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


11E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


11F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


11G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


11H 


Server 


[26] 20.35 








[26] 20.35 








12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









cl : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A. 4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 



identity within trusted networks. 
c4: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c5: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension, 
cl 0: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

cl 1 : IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 
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Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/2 OR A.6/3 OR A.6/4 OR A.6/5 - - Ixx 



Table A.50: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Contact 


[26] 20.10 





m 


[26] 20.10 


m 


m 


6 


P-Media-Authorization 


[31] 6.1 


n/a 


n/a 


[31] 6.1 


c11 


c12 


9 


Rseq 


[27] 7.1 


c2 


m 


[27] 7.1 


c3 


m 


11 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


c2: IF A.4/14 THEN o ELSE n/a - - reliability of provisional responses in SIP. 
c3: IF A.4/14 THEN m ELSE n/a - - reliability of provisional responses in SIP. 
c1 1 : IF A.4/19 THEN m ELSE n/a - - SIP extensions for media authorization. 
c12: IFA.3/1 THEN m ELSE n/a-- UE. 



Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/6 - - 2xx 

Table A.51 : Supported headers within the INVITE response 



Item 


iHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


1A 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


1B 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


2 


Allow 


[26] 20.5 


(note 1) 





[26] 20.5 


m 


m 


4 


Authentication-Info 


[26] 20.6 


Cl 


cl 


[26] 20.6 


c2 


c2 


6 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


8 


P-Media-Authorization 


[31] 6.1 


n/a 


n/a 


[31] 6.1 


c11 


c12 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


m 


m 


13 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



cl : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 

c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

cl 1 : IF A.4/19 THEN m ELSE n/a - - SIP extensions for media authorization. 

c12: IFA.3/1 THEN m ELSE n/a-- UE. 



NOTE 1 : The strength of this requirement in RFC 3261 [26] is RECOMMENDED, rather than OPTIONAL. 

Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/1 1 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.52: Supported headers within the INVITE response 



Item 


iHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Contact 


[26] 20.10 


(note 1 ) 





[26] 20.10 


m 


m 


5 


Error-Info 


[26] 20.18 








[26] 20.18 








10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 
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Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 



Table A.53: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








6 


Proxy-Authenticate 


[26] 20.27 


c3 


c3 


[26] 20.27 


c3 


c3 


10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


13 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/50 OR A.6/51 - - 404, 413, 480, 486, 600, 603 
Table A.54: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








8 


Retry-After 


[26] 20.33 








[26] 20.33 








10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.55: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


5 


Error-Info 


[26] 20.18 








[26] 20.18 








10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 

Table A.56: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








6 


Proxy-Authenticate 


[26] 20.27 







[26] 20.27 







10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


11 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 
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Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/25 - - 415 (Unsupported Media Type) 



Table A.57: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


6 


Error-Info 


[26] 20.18 








[26] 20.18 








11 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 At least one of these capabilities is supportec 


. 



Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.58: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


10 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/9 - - INVITE response 

Prerequisite: A.6/28 OR A. 6/4 1 A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.58A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


3 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


Cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 



Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 

Table A.59: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/42 - - 500 (Server Internal Error) 



Table A.60: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[28] 20.18 








8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 








10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/9 - - INVITE response 
Prerequisite: A.6/45 - - 503 (Service Unavailable) 

Table A.61 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








8 


Retry-After 


[26] 20.33 








[26] 20.33 





m 


10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/9 - - INVITE response 

Table A.62: Supported message bodies within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.7A MESSAGE method 

Prerequisite A.5/9A - - MESSAGE request 



Table A.62A: Supported headers within the MESSAGE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


3 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Call-Info 


[26] 20.9 








[26] 20.9 








6 


Content-Disposition 


[26] 20.1 1 








[26] 20.1 1 


m 


m 


7 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


8 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


9 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


10 


Content-Type 


[26] 20.15 


m 


m 


[26] 29.15 


m 


m 


11 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


12 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


13 


Expires 


[26] 20.19 








[26] 20.19 








14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


In-Reply-To 


[26] 20.21 








[26] 20.21 








16 


Max-Fonwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


17 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


18 


Organization 


[26] 20.25 








[26] 20.25 








18A 


P-Access-Network-lnfo 


[52] 4.4 


c15 


c16 


[52] 4.4 


c15 


c16 


18B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c11 


c11 


18C 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


c13 


c13 


18D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c21 


[52] 4.5 


c20 


c21 


18E 


P-Charging-Vector 


[52] 4.6 


c18 


c19 


[52] 4.6 


c18 


c19 


18F 


P-Preferred-ldentity 


[34] 9.2 


c11 


c7 


[34] 9.2 


n/a 


n/a 


18G 


P-Vlsited-Network-ID 


[52] 4.3 


X (note 1 ) 


X 


[52] 4.3 


c14 


n/a 


19 


Priority 


[26] 20.26 








[26] 20.26 








19A 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c12 


c12 


20 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


21 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


22 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


23 


Reply-To 


[26] 20.31 








[26] 20.31 








24 


Require 


[26] 20.32 


c8 





[26] 20.32 


m 


m 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


25A 


Security-Client 


[48] 2.3.1 


c22 


c22 


[48] 2.3.1 


n/a 


n/a 


25B 


Security-Verify 


[48] 2.3.1 


c23 


c23 


[48] 2.3.1 


n/a 


n/a 


26 


Subject 


[26] 20.35 








[26] 20.36 








27 


Supported 


[26] 20.37 


c9 


m 


[26] 20.37 


m 


m 


28 


Timestamp 


[26] 20.38 


clO 


clO 


[26] 20.38 


m 


m 


29 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


30 


User-Agent 


[26] 20.41 








[26] 20.41 








31 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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Item 



Header 



Ref. 



Sending 



RFC 
status 



Profiie 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



c1: 
c2: 
c3: 
c4: 
c5: 
c7: 

c8: 
c9: 
c10: 
c11: 

c12 
c13 
c14 
c15 
c16 
c17 

c18 
c19 
c20 
c21 
c22 
c23 



IF A.4/20 THEN o ELSE n/a ■ 
IFA.4/20 THEN m ELSE n/a 
IF A.4/7 THEN m ELSE n/a - 
IFA.4/11 THEN ELSE n/a 
IF A.162/8A THEN m ELSE I 



SIP specific event notification extension. 

- SIP specific event notification extension, 
authentication between UA and UA. 
insertion of date in requests and responses. 

- authentication between UA and proxy. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/14 THEN o.1 ELSE o - - Reliable transport. 

IF IF A.4/14 THEN 0.1 ELSE o - - support of reliable transport. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 
IF A.4/33 THEN o ELSE n/a - - the P-Visited-Network-ID extension. 
IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 
■ security mechanism agreement for the session initiation protocol (note 2). 

- security mechanism agreement for the session initiation protocol. 



IFA.4/35 THEN o ELSE n/a 
IF A.4/35 THEN m ELSE n/a 
IF A.4/37 THEN o ELSE n/a 
IF A.4/37 THEN m ELSE n/a 



NOTE 1 : The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 

NOTE 2: Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/9A - - MESSAGE request 

Table A.62B: Supported message bodies within the lUlESSAGE request 



item 


IHeader 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A.5/9B - - MESSAGE response 

Table A.62C: Supported headers within the lUlESSAGE response - all remaining status-codes 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Call-Info 


[26] 20.9 








[26] 20.9 








3 


Content-Disposition 


[26] 20.11 


(note 2) 


(note 2) 


[26] 20.11 


m 

(note 2) 


m 

(note 2) 


4 


Content-Encoding 


[26] 20.12 


(note 2) 


(note 2) 


[26] 20.12 


m 

(note 2) 


m 

(note 2) 


5 


Content-Language 


[26] 20.13 


(note 2) 


(note 2) 


[26] 20.13 


m 

(note 2) 


m 

(note 2) 


6 


Content-Length 


[26] 20.14 


m 

(note 2) 


m 

(note 2) 


[26] 20.14 


m 

(note 2) 


m 

(note 2) 


7 


Content-Type 


[26] 20.15 


m 

(note 2) 


m 

(note 2) 


[26] 20.15 


m 

(note 2) 


m 

(note 2) 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26] 20.17 


c1 


c1 


[26] 20.17 


m 


m 


10 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


1 1 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


12 


Organization 


[26] 20.25 








[26] 20.25 








12A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


12B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


12C 


P-Cliarging-Function- 
Addresses 


[52] 4.5 


clO 


c1 1 


[52] 4.5 


clO 


c1 1 


12D 


P-Cliarging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


12E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


12F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


12G 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


13 


Server 


[26] 20.35 








[26] 20.35 








14 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


15 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


16 


User-Agent 


[26] 20.41 








[26] 20.41 








17 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


18 


Warning 


[26] 20.43 








[26] 20.43 









c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
c4: IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c6: IF A. 4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
c1 1 : IF A. 4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 



NOTE 1 : For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 

NOTE 2: RFC 3428 [50] clause 7 states that all 2xx class responses to a MESSAGE request must not include any 
body, therefore for 2xx responses to the MESSAGE request the values on Sending side for "RFC status" 
and "Profile status" are "x", the values for Receiving side for "RFC status" and "Profile Status" are "n/a". 
RFC 3261 [26] subclause 7.4 states that all responses may contain bodies, therefore for all responses to 
the MESSAGE request other than 2xx responses, the values on Sending side for "RFC status" and "Profile 
status" are "o", the values for Receiving side for "RFC status" and "Profile Status" are "m". 



Prerequisite A.5/9B - - MESSAGE response 
Prerequisite: A.6/6 - - 2xx 

Table A.62D: Supported headers within the MESSAGE response 



Item 



Header 



Sending 



Receiving 
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Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Authentication-Info 


[26] 20.6 


c1 


c1 


[26] 20.6 


c2 


c2 


4 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - autlientication between UA and UA. 



Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.62E: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/9B - - MESSAGE response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.62F: Supported headers within the lUlESSAGE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


cl 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Tabie A.62G: Supported headers within the iUlESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Retry-After 


[26] 20.33 








[26] 20.33 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/9B - - MESSAGE response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 



Table A.62H: Supported headers within the lUlESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 



Table A.62I: Supported headers within the iUIESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Proxy-Authenticate 


[26] 20.27 


c1 


C1 


[26] 20.27 


Cl 


cl 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/9B - - MESSAGE response 
Prerequisite: A.6/25 - - 415 (Unsupported Media Type) 

Table A.62J: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


4 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


5 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 


At least one of these capabilities is supportec 


. 



Prerequisite A.5/9B - - MESSAGE response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.62K: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 
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Prerequisite A.5/9B - - MESSAGE response 

Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.62L: Supported headers within the lUlESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


Cl 


c1 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 



Prerequisite A.5/9B - - MESSAGE response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 

Table A.62IUI: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/9B - - MESSAGE response 



Table A.62N: Supported message bodies within the MESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.8 NOTIFY method 

Prerequisite A.5/10 - - NOTIFY request 



Table A.63: Supported headers within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


17 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


17A 


P-Access-Network-lnfo 


[52] 4.4 


clO 


c11 


[52] 4.4 


clO 


c12 


17B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c6 


c6 


17C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c15 


[52] 4.5 


c14 


c15 


17D 


P-Charging-Vector 


[52] 4.6 


c13 


n/a 


[52] 4.6 


c13 


n/a 


17E 


P-Preferred-ldentity 


[34] 9.2 


c6 


x 


[34] 9.2 


n/a 


n/a 


17F 


Privacy 


[33] 4.2 


c7 


n/a 


[33] 4.2 


c7 


c7 


18 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


19 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


20 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


c9 


c9 


21 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


22A 


Security-Client 


[48] 2.3.1 


c16 


c16 


[48] 2.3.1 


n/a 


n/a 


22B 


Security-Verify 


[48] 2.3.1 


c17 


c17 


[48] 2.3.1 


n/a 


n/a 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


23 


Subscription-State 


[28] 8.2.3 


m 


m 


[28] 8.2.3 


m 


m 


24 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


25 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 








[26] 20.41 








28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3; 
c4: 
c5: 
c6: 

c7: 
c8: 
c9: 

c10: 
c11: 
c12: 

c13: 
c14: 
c15: 
c16: 
c17: 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 
Identity within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
IF A. 4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A. 4/1 5 OR A.4/20 THEN m ELSE n/a - - the REFER method extension or SIP specific event notification 
extension. 

IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note). 
security mechanism agreement for the session Initiation protocol. 



IF A.4/35 THEN m ELSE n/a 
IF A.4/37 THEN o ELSE n/a ■ 
IF A.4/37 THEN m ELSE n/a 



NOTE: Support of this header in this method Is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header In this method Is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/10 - - NOTIFY request 

Table A.64: Supported message bodies within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

status 


Profile 
status 


1 


sipfrag 


[37] 2 


Cl 


cl 


[37] 


cl 


cl 


c1 : IF A.4/15 THEN m ELSE o - - the REFER method extension 
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Prerequisite A.5/1 1 - - NOTIFY response 



Table A.65: Supported headers within the NOTIFY response - all status-codes 



Item 


iHeader 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


d. 


Content- Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


P-Access- Netwo rk- 1 nf o 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


10B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


IOC 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


clO 


[52] 4.5 


c9 


clO 


10D 


P-Cliarging-Vector 


[52] 4.6 


c8 


n/a 


[52] 4.6 


c8 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10F 


Privacy 


[33] 4.2 


c4 


n/a 


[33] 4.2 


c4 


c4 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


10H 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









cl : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2; IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 
c4: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c6: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

clO: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A.6/6 and A.6/7 - - 2xx 



Table A.66: Supported headers within the NOTIFY response 



Item 


iHeader 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


2 


Record-Route 


[26] 20.30 


c3 


c3 


[26] 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



cl : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 

c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

c3: IF A.4/15 OR A.4/20 THEN m ELSE n/a - - the REFER method extension or SIP specific event notification 



extension. 
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Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.67: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Contact 


[26] 20.10 


m (note) 


m 


[26] 20.10 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than MANDATORY for a 485 response. 



Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.68: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Table A.69: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Retry-After 


[26] 20.33 








[26] 20.33 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A.6/18 - 405 (Method Not Allowed) 

Table A.70: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 



Table A.71 : Supported headers within the NOTIFY response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


c3 


c3 


[26] 20.27 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c3: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite A.6/25 - - 415 (Unsupported Media Type) 

Table A.72: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.73: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 

Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.73A: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


c1 


Cl 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 
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Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 



Table A.74: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/1 1 - - NOTIFY response 
Prerequisite: A.6/39 - - 489 (Bad Event) 



Table A.75: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/1 1 - - NOTIFY response 



Table A.76: Supported message bodies within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.9 OPTIONS method 

Prerequisite A.5/12 - - OPTIONS request 



Table A.77: Supported headers within the OPTIONS request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c1 


cl 


5 


Authorization 


[26] 20.7 


c2 


c2 


[26] 20.7 


c2 


c2 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 








[26] 20.9 








8 


Contact 


[26] 20.10 








[26] 20.10 








9 


Content-Disposition 


[26] 20.1 1 








[26] 20.1 1 


m 


m 


10 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


11 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


c3 


c3 


[26] 20.17 


m 


m 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


18 


IVIII^E- Version 


[26] 20.24 








[26] 20.24 


m 


m 


19 


Organization 


[26] 20.25 








[26] 20.25 








19A 


P-Access-Networl<-lnfo 


[52] 4.4 


c11 


c12 


[52] 4.4 


c11 


c13 


19B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c6 


c6 


19C 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


c9 


c9 


19D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c16 


c17 


[52] 4.5 


c16 


c17 


19E 


P-Charging-Vector 


[52] 4.6 


c14 


c15 


[52] 4.6 


c14 


c15 


19F 


P-Preferred-ldentity 


[34] 9.2 


c6 


c4 


[34] 9.2 


n/a 


n/a 


19G 


P-Visited-Network-ID 


[52] 4.3 


X (note 2) 


X 


[52] 4.3 


clO 


n/a 


19H 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c8 


c8 


20 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


21 


Proxy-Require 


[26] 20.29 





(note 1 ) 


[26] 20.29 


n/a 


n/a 


22 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


23 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


24A 


Security-Client 


[48] 2.3.1 


c18 


c18 


[48] 2.3.1 


n/a 


n/a 


24B 


Security-Verify 


[48] 2.3.1 


c19 


c19 


[48] 2.3.1 


n/a 


n/a 


25 


Supported 


[26] 20.37 


c6 


c6 


[26] 20.37 


m 


m 


26 


Timestamp 


[26] 20.38 


c7 


c7 


[26] 20.38 


m 


m 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 








[26] 20.41 








29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3; 
c4: 

c5: 
c6: 

c7: 
c8: 
c9: 
c10 
c11 
c12 
c13 

c14 
c15 
c16 
c17 
c18 
c19 



IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

IF A. 3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 

identity within trusted networks. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

- the P-Called-Party-ID extension, 
-the P-Visited-Network-ID extension. 

- the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charging-Vector header extension. 

- the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 3). 

- security mechanism agreement for the session initiation protocol. 



IF A.4/32 THEN o ELSE n/a 
IF A.4/33 THEN o ELSE n/a 
IF A.4/34 THEN o ELSE n/a 



IF A.4/36 THEN m ELSE n/a 
IF A.4/35 THEN o ELSE n/a 
IF A.4/35 THEN m ELSE n/a 
IF A.4/37 THEN o ELSE n/a 

IF A.4/37 THEN m ELSE n/a 



NOTE 1 : 



NOTE 2: 
NOTE 3: 



No distinction has been made in these tables between first use of a request on a From/To/Call-ID 
combination, and the usage in a subsequent one. Therefore the use of "o" etc. above has been included 
from a viewpoint of first usage. 

The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 
Support of this header in this method is dependent on the security mechanism and the security architecture 
which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/12 - - OPTIONS request 

Table A.78: Supported message bodies within tlie OPTIONS request 



item 


IHeader 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/13 - - OPTIONS response 
Prerequisite: A.6/1 - - 100 (Trying) 



Table A. 79: Supported headers within the OPTIONS response 



Item 


IHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


n/a 


n/a 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


n/a 


n/a 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


n/a 


n/a 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


n/a 


n/a 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


n/a 


n/a 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


n/a 


n/a 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


n/a 


n/a 


[26] 20.42 


m 


m 
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Prerequisite A.5/13 - - OPTIONS response 



Table A.80: Supported headers within the OPTIONS response - all remaining status-codes 



Item 


IHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


uail-mro 


[26J 20.9 








[26J 20.9 








2 


Content- Disposition 


[26] 20.1 1 








[26] 20.1 1 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


c1 


c1 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


1 1 


Organization 


[26] 20.25 








[26] 20.25 








1 1 A 


P-Access-Networl<-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


1 1 B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


1 1C 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


c11 


[52] 4.5 


clO 


c11 


11D 


P-Chiarging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


11E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


11F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


11G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to tfie Session Initiation Protocol (SIP) for asserted 

identity within trusted networl<s. 
c4: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c6: IF A. 4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Oharging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

clO: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c1 1 : IF A. 4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/13 - - OPTIONS response 
Prerequisite: A.6/6 - - 2xx 



Table A.81 : Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


m 


m 


2 


Allow 


[26] 20.5 


(note 1) 





[26] 20.5 


m 


m 


3 


Authentication-Info 


[26] 20.6 


Cl 


Cl 


[26] 20.6 


c2 


c2 


5 


Contact 


[26] 20.10 







[26] 20.10 







8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 


NOTE 1 : The strength of this requirement in RFC 3261 [26] is RECOMMENDED, rather than OPTIONAL. 
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Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.82: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/13 - - OPTIONS response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.83: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


10 


www-Authenticate 


[26] 20.44 







[26] 20.44 







c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Table A.84: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Retry-After 


[26] 20.33 








[26] 20.33 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/13 - - OPTIONS response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.85: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



ETSI 



3GPP TS 24.229 version 5.11 .1 Release 5 1 29 ETSI TS 1 24 229 V5.1 1 .1 (2005-01 ) 

Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 



Table A.86: Supported headers within the OPTIONS response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Proxy-Authenticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


Cl 


cl 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/13 - - OPTIONS response 
Prerequisite: A.6/25 - - 415 (Unsupported Media Type) 

Table A.87: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


4 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


5 


Error-Info 


[26] 20.18 








[26] 20.18 








8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 


At least one of these capabilities is supportec 


. 



Prerequisite A.5/13 - - OPTIONS response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.88: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/13 - - OPTIONS response 

Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.88A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protoco 
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Prerequisite A.5/13 - - OPTIONS response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 



Table A.89: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/13 - - OPTIONS response 



Table A.90: Supported message bodies within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















ETSI 



3GPP TS 24.229 version 5.11 .1 Release 5 1 31 ETSI TS 1 24 229 V5.1 1 .1 (2005-01 ) 

A.2.1.3.10 PRACK method 

Prerequisite A.5/14 - - PRACK request 



Table A.91 : Supported headers within the PRACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


IVIax-Fonwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


16 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c9 


clO 


[52] 4.4 


c9 


c11 


16B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c13 


c14 


[52] 4.5 


c13 


c14 


16C 


P-Charging-Vector 


[52] 4.6 


c12 


n/a 


[52] 4.6 


c12 


n/a 


16D 


Privacy 


[33] 4.2 


c6 


n/a 


[33] 4.2 


c6 


n/a 


17 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


18 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


19 


RAck 


[27] 7.2 


m 


m 


[27] 7.2 


m 


m 


20 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


21 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


23 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


24 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


25 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


26 


User-Agent 


[26] 20.41 








[26] 20.41 








27 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



cl : IF A.4/20 THEN o ELSE n/a - - SIP specific event notification extension. 

c2: IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. 

c3: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 

c4: IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c5: IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

c6: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c8: IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

c9: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

cl 0: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

cl 1 : IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

c12: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c14: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 
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Prerequisite A.5/14 - - PRACK request 



Table A.92: Supported message bodies within tlie PRACK request 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/15 - - PRACK response 
Prerequisite: A.6/1 - - 100 (Trying) 



Tabie A.93: Supported lieaders witliin tlie PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


n/a 


n/a 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


n/a 


n/a 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


n/a 


n/a 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


n/a 


n/a 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


n/a 


n/a 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


n/a 


n/a 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


n/a 


n/a 


[26] 20.42 


m 


m 
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Prerequisite A.5/15 - - PRACK response 



Table A.94: Supported headers within the PRACK response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.1 1 








[26] 20.1 1 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


c1 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


P-Access-Networl<-lnfo 


[52] 4.4 


c3 


c4 


[52] 4.4 


c3 


c5 


1 0B 


P-CPnarging-Function- 
Addresses 


[52] 4.5 


c7 


c8 


[52] 4.5 


c7 


c8 


10C 


P-Cliarging-Vector 


[52] 4.6 


c6 


n/a 


[52] 4.6 


c6 


n/a 


10D 


Privacy 


[33] 4.2 


c2 


n/a 


[33] 4.2 


c2 


n/a 


10E 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


10F 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









c1 : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c3: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c4: IF A. 4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c5; IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 



AS acting as terminating UA or AS acting as third-party call controller. 
c6: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c7: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c8: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/15 - - PRACK response 
Prerequisite: A.6/6 - - 2xx 



Table A.95: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


OB 


Authentication-Info 


[26] 20.6 


C1 


C1 


[26] 20.6 


c2 


c2 


3 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
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Prerequisite A.5/15 - - PRACK response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.96: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/15 - - PRACK response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.97: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/15 - - PRACK response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Table A.98: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Retry-After 


[26] 20.33 








[26] 20.33 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/15 - - PRACK response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.99: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/15 - - PRACK response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 



Table A.100: Supported headers within the PRACK response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


Cl 


cl 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/15 - - PRACK response 
Prerequisite: A.6/25 - - 415 (Unsupported Media Type) 

Table A.I 01 : Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/15 - - PRACK response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.102: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/15 - - PRACK response 

Prerequisite: A.6/28 OR A. 6/41 A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.102A: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


Cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 
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Prerequisite A.5/15 - - PRACK response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 



Table A.103: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/15 - - PRACK response 



Table A.I 04: Supported message bodies within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















ETSI 



3GPP TS 24.229 version 5.11 .1 Release 5 1 37 ETSI TS 1 24 229 V5.1 1 .1 (2005-01 ) 

A.2.1.4.11 REFER method 

Prerequisite A.5/16 - - REFER request 



Table A.I 05: Supported headers within the REFER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


OB 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


1 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


1 A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


3 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


5A 


Content-Disposition 


[26] 20.1 1 








[26] 20.11 


m 


m 


5B 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


5C 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


6 


Content-Lengtli 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


10 


Expires 


[26] 20.19 








[26] 20.19 








11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


12 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


13 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


14 


Organization 


[26] 20.25 








[26] 20.25 








14A 


P-Access-Networl<-lnfo 


[52] 4.4 


c12 


c13 


[52] 4.4 


c12 


c14 


148 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c8 


c8 


14C 


P-Called-Party-ID 


[52] 4.2 


X 


X 


[52] 4.2 


clO 


clO 


14D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c17 


c18 


[52] 4.5 


c17 


c18 


14E 


P-Charging-Vector 


[52] 4.6 


c15 


c16 


[52] 4.6 


c15 


c16 


14F 


P-Preferred-ldentity 


[34] 9.2 


c8 


c7 


[34] 9.2 


n/a 


n/a 


14G 


P-Visited-Network-ID 


[52] 4.3 


X (note 1 ) 


X 


[52] 4.3 


c11 


n/a 


14H 


Privacy 


[33] 4.2 


c9 


c9 


[33] 4.2 


c9 


c9 


15 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


16 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


17 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


m 


m 


18 


Refer-To 


[36] 3 


m 


m 


[36] 3 


m 


m 


19 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


20 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


20A 


Security-Client 


[48] 2.3.1 


c19 


c19 


[48] 2.3.1 


n/a 


n/a 


208 


Security-Verify 


[48] 2.3.1 


c20 


c20 


[48] 2.3.1 


n/a 


n/a 


20C 


Subject 


[26] 20.36 








[26] 20.36 








21 


Supported 


[26] 

20.37, 
[26] 7.1 








[26] 

20.37, 
[26] 7.1 


m 


m 


22 


Timestamp 


[26] 20.38 


c6 


c6 


[26] 20.38 


m 


m 


23 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


24 


User-Agent 


[26] 20.41 








[26] 20.41 








25 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3; 
c4: 
c5: 
c6: 
c7: 

c8: 

c9: 
c10 
c11 
c12 
c13 
c14 

c15 
c16 
c17 
c18 
c19 
c20 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 
IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A.3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 
identity within trusted networks. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session initiation Protocol (SIP). 
IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 
IF A.4/33 THEN o ELSE n/a - - the P-Vlslted-Network-ID extension. 
IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charglng-Vector header extension. 
IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charglng-Functlon-Addresses header extension. 

- the P-Charglng-Functlon-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 2). 
security mechanism agreement for the session initiation protocol. 



IFA.4/35 THEN o ELSE n/a 
IF A.4/35 THEN m ELSE n/a 
IF A.4/37 THEN o ELSE n/a 
IF A.4/37 THEN m ELSE n/a 



NOTE 1 : The strength of this requirement in RFC 3455 [52] is SHOULD NOT, rather than MUST NOT. 
NOTE 2: Support of this header in this method Is dependent on the security mechanism and the security architecture 

which Is Implemented. Use of this header In this method Is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/16 - - REFER request 

Table A.106: Supported message bodies within tlie REFER request 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/17 - - REFER response 
Prerequisite: A. 6/1 - - 100 (Trying) 



Tabie A.107: Supported lieaders witliin tlie REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


n/a 


n/a 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


n/a 


n/a 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


n/a 


n/a 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


n/a 


n/a 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


n/a 


n/a 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


n/a 


n/a 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


n/a 


n/a 


[26] 20.42 


m 


m 
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Prerequisite A.5/17 - - REFER response 

Table A.108: Supported headers within the REFER response - all remaining status-codes 



Item 


iHeader 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


Content- Disposition 


[26J 20.1 1 








[26] 20.1 1 


m 


m 


2 


Content- Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


3 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


4 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


5 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


6 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


7 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


8 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9 


IVIIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10 


Organization 


[26] 20.25 








[26] 20.25 








10A 


P-Access-Network-lnfo 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


10B 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


10C 


P-Cliarging-Function- 
Addresses 


[52] 4.5 


clO 


cl 1 


[52] 4.5 


clO 


cl 1 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


10E 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10F 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


10H 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









cl : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to tiie Session Initiation Protocol (SIP) for asserted 

identity witiiin trusted networl<s. 
c4: IF A.4/26 THEN o ELSE n/a - - a privacy meciianism for tine Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c6: IF A. 4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Oharging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
cl 1 : IF A. 4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 



NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/17 - - REFER response 
Prerequisite: A.6/7 - - 202 (Accepted) 



Table A.109: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


5 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


m 


m 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


Cl : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
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Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.110: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/17 - - REFER response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.111: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Table A.112: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








6 


Retry-After 


[26] 20.33 








[26] 20.33 








8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/17 - - REFER response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.113: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 



Table A.114: Supported headers within the REFER response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Proxy-Authenticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


Cl 


cl 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/25 - - 415 (Unsupported Media Type) 

Table A.1 15: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 At least one of these capabilities is supportec 


. 



Prerequisite A.5/17 - - REFER response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.116: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/17 - - REFER response 

Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.116A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protoco 
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Prerequisite A.5/17 - - REFER response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 



Table A.117: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/17 - - REFER response 



Table A.118: Supported message bodies within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.12 REGISTER method 

Prerequisite A.5/18 - - REGISTER request 



Table A.1 19: Supported headers within the REGISTER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c1 


cl 


5 


Authorization 


[26] 20.7, 
[49] 


c2 





[26] 20.7, 
[49] 


m 


c22 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 








[26] 20.9 








8 


Contact 


[26] 20.10 








[26] 20.10 


m 


m 


9 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


10 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


11 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


12 


Content-Lengtli 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


c3 


c3 


[26] 20.17 


m 


m 


16 


Expires 


[26] 20.19 








[26] 20.19 


m 


m 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


18 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


19 


IVIII^/IE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


20 


Organization 


[26] 20.25 








[26] 20.25 








20A 


P-Access-Networl<-lnfo 


[52] 4.4 


c12 


c13 


[52] 4.4 


c12 


c14 


20B 


P-Cliarging-Function- 
Addresses 


[52] 4.5 


c17 


c18 


[52] 4.5 


c17 


c18 


20C 


P-Cliarging-Vector 


[52] 4.6 


c15 


c16 


[52] 4.6 


c15 


c16 


20D 


P-Visited-Networl<-ID 


[52] 4.3 


X (note 2) 


X 


[52] 4.3 


clO 


c11 


20E 


Patli 


[35] 4 


c4 


c5 


[35] 4 


m 


c6 


20F 


Privacy 


[33] 4.2 


c9 


n/a 


[33] 4.2 


c9 


n/a 


21 


Proxy-Autinorization 


[26] 20.28 


c8 


c8 


[26] 20.28 


n/a 


n/a 


22 


Proxy-Require 


[26] 20.29 





(note 1 ) 


[26] 20.29 


n/a 


n/a 


23 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


24 


Route 


[26] 20.34 





n/a 


[26] 20.34 


n/a 


n/a 


24A 


Security-Client 


[48] 2.3.1 


c19 


c20 


[48] 2.3.1 


n/a 


n/a 


24B 


Security-Verify 


[48] 2.3.1 


c20 


c20 


[48] 2.3.1 


c21 


n/a 


25 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


26 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c7 


c7 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 








[26] 20.41 








29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3; 
c4: 

c5: 

c6: 
c7: 
c8: 
c9: 
c10 
c11 
c12 
c13 

c14: 

c15: 
c16: 

c17: 
c18: 

c19 
c20 
c21 

c22: 



IF A.4/20 THEN m ELSE n/a ■ 
IF A.4/8 THEN m ELSE n/a - 
IF A.4/11 THEN o ELSE n/a - 
IF A.4/24 THEN o ELSE n/a - 
contacts. 

IF A.4/24 THEN x ELSE n/a - 
contacts. 

IF A.3/4 THEN m ELSE n/a. - 
IF A.4/6 THEN m ELSE n/a - 
IF A.4/8ATHEN m ELSE n/a 
IF A.4/26 THEN o ELSE n/a - 
IFA.4/33 THEN ELSE n/a - 
IF A.4/33 THEN m ELSE n/a 



- SIP specific event notification extension, 
authentication between UA and registrar. 

- insertion of date in requests and responses. 

- session initiation protocol extension header field for registering non-adjacent 

- session Initiation protocol extension header field for registering non-adjacent 

- S-CSCF. 

timestamping of requests. 
■ - authentication between UA and proxy. 

- a privacy mechanism for the Session Initiation Protocol (SIP), 
-the P-Visited-Network-ID extension. 

- the P-Visited-Network-ID extension. 

- the P-Access-Network-lnfo header extension, 
the P-Access-Network-lnfo header extension and UE 



■ the P-Access-Network-lnfo header extension and 



IF A.4/34 THEN ELSE n/a 

IF A.4/34 AND (A.3/1 OR A.3/4) THEN o ELSE n/a - - 
or S-CSCF (note 4). 

IF A.4/34 AND (A.3/4 OR A.3/7A) THEN m ELSE n/a 
S-CSCF or AS acting as terminating UA. 

IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Charglng-Vector header extension (Including S-CSCF as 

registrar). 

IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

IF A. 4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including 

S-CSCF as registrar). 

IF A.4/37 THEN o ELSE n/a - - security mechanism agreement for the session initiation protocol (note 3). 
IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session Initiation protocol. 
IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session Initiation protocol 
and registrar. 

IF A.3/4 THEN m ELSE n/a - - S-CSCF. 



NOTE 1 : No distinction has been made in these tables between first use of a request on a From/To/Call-ID 

combination, and the usage In a subsequent one. Therefore the use of "o" etc. above has been Included 
from a viewpoint of first usage. 

NOTE 2: The strength of this requirement In RFC 3455 [52] Is SHOULD NOT, rather than MUST NOT. 

NOTE 3: Support of this header in this method Is dependent on the security mechanism and the security architecture 
which is Implemented. 

NOTE 4: Refere to subclause 5.1 .1 .2 for Information on when the UE sets the P-Access-Network-lnfo header. 



Prerequisite A.5/18 - - REGISTER request 

Table A.120: Supported message bodies within the REGISTER request 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/1 - - 100 (Trying) 



Table A.121 : Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


n/a 


n/a 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


n/a 


n/a 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


n/a 


n/a 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


n/a 


n/a 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


n/a 


n/a 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


n/a 


n/a 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


n/a 


n/a 


[26] 20.42 


m 


m 
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Prerequisite A.5/19 - - REGISTER response 



Table A.122: Supported headers within the REGISTER response - all status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


uail-mro 


[26J 20.9 








[26J 20.9 








2 


Content- Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


c1 


c1 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


1 1 


Organization 


[26] 20.25 








[26] 20.25 








1 1 A 


P-Access-Networl<- 1 nf o 


[52] 4.4 


c3 


n/a 


[52] 4.4 


c3 


n/a 


1 1 B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c6 


c7 


[52] 4.5 


c6 


c7 


11C 


P-Charging-Vector 


[52] 4.6 


c4 


c5 


[52] 4.6 


c4 


c5 


11D 


Privacy 


[33] 4.2 


c2 


n/a 


[33] 4.2 


c2 


n/a 


11E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


11F 


Server 


[26] 20.35 








[26] 20.35 








12 


Timestamp 


[26] 20.38 


c2 


c2 


[26] 20.38 


m 


m 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 








[26] 20.41 








14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c3: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c4: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c5: IF A.4/36 OR A.3/4 THEN m ELSE n/a - - the P-Gharging-Vector header extension (including S-CSCF as 

registrar). 

c6: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c7: IF A. 4/35 OR A.3/4 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension (including 

S-CSCF as registrar). 

NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 
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Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/6 - - 2xx 



Table A.123: Supported headers within the REGISTER response 



Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



Accept 



[26] 20.1 



[26] 20.1 



1A 



Accept-Encoding 



[26] 20.2 



[26] 20.2 



m 



m 



1B 



Accept-Language 



[26] 20.3 



[26] 20.3 



m 



m 



Allow 



[26] 20.5 



[26] 20.5 



m 



m 



Authentication-info 



[26] 20.6 



c6 



c6 



[26] 20.6 



c7 



c7 



Contact 



[26] 20.10 



[26] 20.10 



m 



m 



5A 



P-Associated-URI 



[52] 4.1 



c8 



c9 



[52] 4.1 



clO 



c11 



Path 



[35] 4 



c3 



c3 



[35] 4 



c4 



c4 



Service-Route 



[38] 5 



c5 



c5 



[38] 5 



c5 



c5 



Supported 



[26] 20.37 



m 



m 



[26] 20.37 



m 



m 



session initiation protocol extension header field for registering non- 
session initiation protocol extension header field for registering non-adjacent 



c1 : IF (A.3/4 AND A.4/2) THEN m ELSE n/a. - - S-CSCF acting as registrar. 
c2: IF A.3/4 OR A.3/1THEN m ELSE n/a. - - S-CSCF or UE. 

c3: IF A.4/24 THEN m ELSE n/a 

adjacent contacts. 
c4; IF A.4/24 THEN ELSE n/a 

contacts. 

c5: IF A.4/28 THEN m ELSE n/a - - session initiation protocol extension header field for service route discovery 
during registration. 

c6: IF A.4/8 THEN o ELSE n/a - - authentication between UA and registrar. 

c7: IF A.4/8 THEN m ELSE n/a - - authentication between UA and registrar. 

c8: IF A.4/2 AND A.4/31 THEN m ELSE n/a - - P-Assocated-URI header extension and registrar. 

c9: IF A.3/1 AND A.4/31 THEN m ELSE n/a - - P-Assocated-URI header extension and S-CSCF. 

clO: IF A.4/31 THEN o ELSE n/a - - P-Assocated-URI header extension. 

c1 1 : IF A.4/31 AND A.3/1 THEN m ELSE n/a - - P-Assocated-URI header extension and UE. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/I0 OR A.6/I I OR A.6/I2 OR A.6/35 - - 3xx or 485 (Ambiguous) 
Table A.124: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOIVIMENDED rather than OPTIONAL. 
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Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 



Table A.125: Supported headers within the REGISTER response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Proxy-Authenticate 


[26] 20.27 


Cl 


X 


[26] 20.27 


cl 


X 


6 


Security-Server 


[48] 2 


X 


X 


[48] 2 


n/a 


c2 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/8 THEN m ELSE n/a - - support of authentication between UA and UA. 






c2: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protocol. 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Table A.126: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








6 


Retry-After 


[26] 20.33 








[26] 20.33 








8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.127: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


4 


Error-Info 


[26] 20.18 








[26] 20.18 








8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 

Table A.I 28: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 

status 


Profile 

status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Proxy-Authenticate 


[26] 20.27 


c1 


X 


[26] 20.27 


cl 


X 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


9 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/8 THEN m ELSE n/a - - support of authentication between UA and UA. 
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Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/25 - - 415 (Unsupported Media Type) 



Table A.129: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


4 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


5 


Error-Info 


[26] 20.18 








[26] 20.18 








g 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 


At least one of these capabilities is supportec 


. 



Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.130: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/19 - - REGISTER response 

Prerequisite: A.6/28 OR A. 6/4 1 A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.130A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c2 


c2 


[48] 2 


Cl 


cl 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
c2: IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol 
and registrar. 



Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/29 - - 423 (Interval Too Brief) 

Table A.131 : Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 







[26] 20.18 







5 


MIn-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


m 


m 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/19 - - REGISTER response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 



Table A.132: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/19 - - REGISTER response 



Table A.I 33: Supported message bodies within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.13 SUBSCRIBE method 

Prerequisite A.5/20 - - SUBSCRIBE request 



Table A.I 34: Supported headers within the SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


3A 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


4 


Allow-Events 


[28] 7.2.2 


Cl 


cl 


[28] 7.2.2 


c2 


c2 


5 


Authorization 


[26] 20.7 


c3 


c3 


[26] 20.7 


c3 


c3 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


7 


Content-Disposition 


[26] 20.1 1 








[26] 20.1 1 


m 


m 


8 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


9 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


c4 


c4 


[26] 20.17 


m 


m 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


Expires 


[26] 20.19 


(note 1 ) 


(note 1 ) 


[26] 20.19 


m 


m 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17 


Max-Fon«ards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


18 


MIME-Version 


[26] 20.24 








[26] 20.24 


m 


m 


18A 


Organization 


[26] 20.25 








[26] 20.25 








18B 


P-Access-Networl<-lnfo 


[52] 4.4 


c12 


c13 


[52] 4.4 


c12 


c14 


18C 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c6 


c6 


18D 


P-Called-Party-ID 


[52] 4.2 


x 


X 


[52] 4.2 


ClO 


clO 


18E 


P-Charging-Function- 
Addresses 


[52] 4.5 


c17 


c18 


[52] 4.5 


c17 


c18 


18F 


P-Charging-Vector 


[52] 4.6 


c15 


c16 


[52] 4.6 


c15 


c16 


18G 


P-Preferred-ldentity 


[34] 9.2 


c6 


c7 


[34] 9.2 


n/a 


n/a 


18H 


P-Visited-Networl<-ID 


[52] 4.3 


X (note 2) 


X 


[52] 4.3 


c11 


n/a 


181 


Privacy 


[33] 4.2 


c9 


c9 


[33] 4.2 


c9 


c9 


19 


Proxy-Authorization 


[26] 20.28 


c5 


c5 


[26] 20.28 


n/a 


n/a 


20 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


21 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


m 


m 


22 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


23 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


23A 


Security-Client 


[48] 2.3.1 


c19 


c19 


[48] 2.3.1 


n/a 


n/a 


23B 


Security-Verify 


[48] 2.3.1 


c20 


c20 


[48] 2.3.1 


n/a 


n/a 


24 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


25 


Timestamp 


[26] 20.38 


c8 


c8 


[26] 20.38 


m 


m 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 








[26] 20.41 








28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1: 
c2: 
c3; 
c4: 
c5: 
c6: 

c7: 

c8: 
c9: 
c10 
c11 
c12 
c13 
c14 

c15 
c16 
c17 
c18 
c19 
c20 



IF A. 4/20 THEN o ELSE n/a - - SIP specific event notification extension. 
IF A. 4/20 THEN m ELSE n/a - - SIP specific event notification extension. 
IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 
IF A.4/8A THEN m ELSE n/a - - authentication between UA and proxy. 

IF A.4/25 THEN o ELSE n/a - - private extensions to the Session Initiation Protocol (SIP) for asserted 
Identity within trusted networks. 

IF A. 3/1 AND A.4/25 THEN o ELSE n/a - - UE and private extensions to the Session Initiation Protocol 

(SIP) for asserted identity within trusted networks. 

IF A.4/6 THEN o ELSE n/a - - timestamping of requests. 

IF A. 4/26 THEN o ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
IF A.4/32 THEN o ELSE n/a - - the P-Called-Party-ID extension. 
IF A.4/33 THEN o ELSE n/a - - the P-Vlslted-Network-ID extension. 
IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 
IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charglng-Vector header extension. 
IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

- the P-Charglng-Functlon-Addresses header extension. 

- the P-Charglng-Functlon-Addresses header extension. 

- security mechanism agreement for the session initiation protocol (note 3). 
security mechanism agreement for the session initiation protocol. 



IFA.4/35 THEN o ELSE n/a 
IF A.4/35 THEN m ELSE n/a 
IF A.4/37 THEN o ELSE n/a 
IF A.4/37 THEN m ELSE n/a 



NOTE 1 : The strength of this requirement is RECOIVIMENDED rather than OPTIONAL. 
NOTE 2: The strength of this requirement In RFC 3455 [52] Is SHOULD NOT, rather than MUST NOT. 
NOTE 3: Support of this header In this method Is dependent on the security mechanism and the security architecture 

which Is Implemented. Use of this header In this method Is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 



Prerequisite A.5/20 - - SUBSCRIBE request 

Table A.I 35: Supported message bodies within tlie SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A.5/21 - - SUBSCRIBE response 

Table A.136: Supported headers within the SUBSCRIBE response - all status-codes 



item 


IHeader 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


d. 


Content- Disposition 


[26J 20.1 1 








[26] 20.1 1 


m 


m 


3 


Content- Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


Organization 


[26] 20.25 








[26] 20.25 








10B 


P-Access-N etwo rk- 1 nf o 


[52] 4.4 


c5 


c6 


[52] 4.4 


c5 


c7 


IOC 


P-Asserted-ldentity 


[34] 9.1 


n/a 


n/a 


[34] 9.1 


c3 


c3 


10D 


P-Cliarging-Function- 
Addresses 


[52] 4.5 


clO 


cl 1 


[52] 4.5 


clO 


cl 1 


10E 


P-Cliarging-Vector 


[52] 4.6 


c8 


c9 


[52] 4.6 


c8 


c9 


10F 


P-Preferred-ldentity 


[34] 9.2 


c3 


X 


[34] 9.2 


n/a 


n/a 


10G 


Privacy 


[33] 4.2 


c4 


c4 


[33] 4.2 


c4 


c4 


10H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


101 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









cl : IF A.4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2: IF A.4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/25 THEN o ELSE n/a - - private extensions to tiie Session Initiation Protocol (SIP) for asserted 

identity witiiin trusted networl<s. 
c4: IF A.4/26 THEN o ELSE n/a - - a privacy mectianism for tine Session Initiation Protocol (SIP). 
c5: IF A. 4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c6: IF A. 4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c7: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 
c8: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c9: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
clO: IF A. 4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 
cl 1 : IF A. 4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 



NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/6 and A.6/7 - - 2xx 

Table A.137: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Authentication-Info 


[26] 20.6 


cl 


cl 


[26] 20.6 


c2 


c2 


1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


2 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


m 


m 


4 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


m 


m 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
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Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/35 - - 3xx or 485 (Ambiguous) 



Table A.138: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Contact 


[26] 20.10 


m (note) 


m 


[26] 20.10 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than MANDATORY for a 485 response. 



Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.139: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


Cl 


cl 


[26] 20.27 


cl 


c1 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/50 OR A.6/51 - - 404, 413, 480, 486, 500, 
600, 603 

Table A.140: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Retry-After 


[26] 20.33 







[26] 20.33 







5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.141: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 



Table A.142: Supported headers within the SUBSCRIBE response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Proxy-Authenticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


Cl 


cl 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


6 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite A.6/25 - - 415 (Unsupported Media Type) 

Table A.143: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


4 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


6 


Server 


[26] 20.35 








[26] 20.35 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 At least one of these capabilities is supportec 


. 



Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.144: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/21 - - SUBSCRIBE response 

Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.144A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protoco 
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Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/29 - - 423 (Interval Too Brief) 



Table A.145: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








2 


Min-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/34 - - 484 (Address Incomplete) 

Table A.146: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/39 - - 489 (Bad Event) 

Table A.147: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 









Prerequisite A.5/21 - - SUBSCRIBE response 
Prerequisite: A.6/45 - - 503 (Service Unavailable) 

Table A.148: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


1 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Retry-After 


[26] 20.33 








[26] 20.33 





m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/21 - - SUBSCRIBE response 



Table A.149: Supported message bodies within the SUBSCRIBE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.1.4.14 UPDATE method 

Prerequisite A.5/22 - - UPDATE request 



Table A.I 50: Supported headers within the UPDATE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


4 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


5 


Allow-Events 


[28] 7.2.2 


c2 


c2 


[28] 7.2.2 


c3 


c3 


6 


Authorization 


[26] 20.7 


c4 


c4 


[26] 20.7 


c4 


c4 


7 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Call-Info 


[26] 20.9 








[26] 20.9 








9 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


10 


Content-Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


11 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


12 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


13 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


14 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


15 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


16 


Date 


[26] 20.17 


c5 


c5 


[26] 20.17 


m 


m 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


18 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


n/a 


n/a 


19 


IVIII^E- Version 


[26] 20.24 








[26] 20.24 


m 


m 


20 


Organization 


[26] 20.25 








[26] 20.25 








20A 


P-Access-Networl<-lnfo 


[52] 4.4 


c11 


c12 


[52] 4.4 


c11 


c13 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c16 


c17 


[52] 4.5 


c16 


c17 


20C 


P-Charging-Vector 


[52] 4.6 


c14 


c15 


[52] 4.6 


c14 


c15 


20D 


Privacy 


[33] 4.2 


c6 


n/a 


[33] 4.2 


c6 


n/a 


21 


Proxy-Authorization 


[26] 20.28 


clO 


clO 


[26] 20.28 


n/a 


n/a 


22 


Proxy-Require 


[26] 20.29 





n/a 


[26] 20.29 


n/a 


n/a 


23 


Record-Route 


[26] 20.30 


n/a 


n/a 


[26] 20.30 


n/a 


n/a 


24 


Require 


[26] 20.32 








[26] 20.32 


m 


m 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


n/a 


n/a 


25A 


Security-Client 


[48] 2.3.1 


c18 


c18 


[48] 2.3.1 


n/a 


n/a 


25B 


Security-Verify 


[48] 2.3.1 


c19 


c19 


[48] 2.3.1 


n/a 


n/a 


26 


Supported 


[26] 20.37 








[26] 20.37 


m 


m 


27 


Timestamp 


[26] 20.38 


c9 


c9 


[26] 20.38 


m 


m 


28 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


29 


User-Agent 


[26] 20.41 








[26] 20.41 








30 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



c2: 
c3: 
c4: 
c5: 
c6: 
c9: 
ClO 
c11 
c12 
c13 

c14 
c15 
c16 
c17 
c18 
c19 



IF A.4/20 THEN o ELSE n/a - 
IF A.4/20 THEN m ELSE n/a 
IFA.4/7 THEN m ELSE n/a - 
IFA.4/11 THEN ELSE n/a - 
IF A.4/26 THEN o ELSE n/a - 
IFA.4/6 THEN ELSE n/a - - 
IF A.4/8ATHEN m ELSE n/a 
IF A.4/34 THEN o ELSE n/a - 



- SIP specific event notification extension. 

- SIP specific event notification extension, 
authentication between UA and UA. 

- insertion of date in requests and responses. 

- a privacy mechanism for the Session Initiation Protocol (SIP), 
timestamping of requests. 

■ - authentication between UA and proxy. 

- the P-Access-Network-lnfo header extension. 

IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Networl<-lnfo header extension and UE. 
IF A.4/34 AND {A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Networl<-lnfo header extension and 
AS acting as terminating UA or AS acting as third-party call controller. 
IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

■ the P-Charging-Function-Addresses header extension. 

- the P-Charging-Function-Addresses header extension, 
security mechanism agreement for the session initiation protocol (note). 

- security mechanism agreement for the session initiation protocol. 



IF A.4/35 THEN o ELSE n/a 
IF A.4/35 THEN m ELSE n/a 
IFA.4/37 THEN ELSE n/a 
IFA.4/37 THEN m ELSE n/a 



NOTE: Support of this header in this method is dependent on the security mechanism and the security architecture 

which is implemented. Use of this header in this method is not appropriate to the security mechanism 
defined by 3GPP TS 33.203 [19]. 
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Prerequisite A.5/22 - - UPDATE request 



Table A.151: Supported message bodies within tlie UPDATE request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A.5/23 - - UPDATE response 

Table A.152: Supported headers within the UPDATE response - all remaining status-codes 



Item 


iHeader 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


uail-mro 


[26J 20.9 








[26J 20.9 








2 


Content- Disposition 


[26] 20.11 








[26] 20.11 


m 


m 


3 


Content-Encoding 


[26] 20.12 








[26] 20.12 


m 


m 


4 


Content-Language 


[26] 20.13 








[26] 20.13 


m 


m 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


m 


m 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


c1 


c1 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIIVIE-Version 


[26] 20.24 








[26] 20.24 


m 


m 


10A 


Organization 


[26] 20.25 








[26] 20.25 








10B 


P-Access-Networl<-lnfo 


[52] 4.4 


c4 


c5 


[52] 4.4 


c4 


c6 


10C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


c10 


[52] 4.5 


c9 


c10 


10D 


P-Charging-Vector 


[52] 4.6 


c7 


c8 


[52] 4.6 


c7 


c8 


10E 


Privacy 


[33] 4.2 


c3 


n/a 


[33] 4.2 


c3 


n/a 


10F 


Require 


[26] 20.31 


m 


m 


[26] 20.31 


m 


m 


10G 


Server 


[26] 20.35 








[26] 20.35 








11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


c2 


c2 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 








[26] 20.41 








13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


(note) 





[26] 20.43 









c1 : IF A. 4/1 1 THEN o ELSE n/a - - insertion of date in requests and responses. 

c2; IF A. 4/6 THEN m ELSE n/a - - timestamping of requests. 

c3: IF A.4/26 THEN o ELSE n/a - - a privacy meclianism for ttie Session Initiation Protocol (SIP). 

c4: IF A.4/34 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 

c5: IF A.4/34 AND A.3/1 THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and UE. 

c6: IF A.4/34 AND (A.3/7A OR A.3/7D) THEN m ELSE n/a - - the P-Access-Network-lnfo header extension and 

AS acting as terminating UA or AS acting as third-party call controller. 

c7: IF A.4/36 THEN o ELSE n/a - - the P-Charging-Vector header extension. 

c8: IF A.4/36 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.4/35 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c1 0: IF A.4/35 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 



NOTE: For a 606 (Not Acceptable Here) response, this status is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/23 - - UPDATE response 
Prerequisite: A.6/6 - - 2xx 



Table A.153: Supported headers within the UPDATE response 



Item 


IHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Accept 


[26] 20.1 








[26] 20.1 


m 


m 


OB 


Accept-Encoding 


[26] 20.2 








[26] 20.2 


m 


m 


OC 


Accept-Language 


[26] 20.3 








[26] 20.3 


m 


m 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Authentication-Info 


[26] 20.6 


Cl 


cl 


[26] 20.6 


c2 


c2 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


m 


m 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1 : IF A.4/7 THEN o ELSE n/a - - authentication between UA and UA. 
c2: IF A.4/7 THEN m ELSE n/a - - authentication between UA and UA. 
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Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 - - 3xx 



Table A.154: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Contact 


[26] 20.10 








[26] 20.10 








3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/23 - - UPDATE response 
Prerequisite: A.6/14 - - 401 (Unauthorized) 

Table A.154A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Proxy-Authenticate 


[26] 20.27 







[26] 20.27 







5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


m 


m 


c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/17 OR A.6/23 OR A.6/30 OR A.6/36 OR A.6/42 OR A.6/45 OR A.6/50 OR A.6/51 - - 404, 413, 480, 
486, 500, 503, 600, 603 

Table A.155: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








5 


Retry-After 


[26] 20.33 








[26] 20.33 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 



Prerequisite A.5/23 - - UPDATE response 
Prerequisite: A.6/18 - - 405 (Method Not Allowed) 

Table A.156: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 
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Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/20 - - 407 (Proxy Authentication Required) 



Table A.157: Supported headers within the UPDATE response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








4 


Proxy-Authenticate 


[26] 20.27 


c1 


c1 


[26] 20.27 


Cl 


cl 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


8 


www-Authenticate 


[26] 20.44 








[26] 20.44 








c1: 


IF A.5/7 THEN m ELSE n/a - - support of authentication between UA and UA. 







Prerequisite A.5/23 - - UPDATE response 
Prerequisite: A.6/25 - - 415 (Unsupported Media Type) 

Table A.I 58: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


0.1 


0.1 


[26] 20.1 


m 


m 


2 


Accept-Encoding 


[26] 20.2 


0.1 


0.1 


[26] 20.2 


m 


m 


3 


Accept-Language 


[26] 20.3 


0.1 


0.1 


[26] 20.3 


m 


m 


4 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


6 


Error-Info 


[26] 20.18 








[26] 20.18 








10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


0.1 At least one of these capabilities is supportec 


. 



Prerequisite A.5/23 - - UPDATE response 
Prerequisite: A.6/27 - - 420 (Bad Extension) 

Table A.159: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


m 


m 



Prerequisite A.5/23 - - UPDATE response 

Prerequisite: A.6/28 OR A.6/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.159A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


X 


X 


[48] 2 


cl 


cl 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


cl: 


IF A.4/37 THEN m ELSE n/a - - 


security mechanism agreement for the session initiation protoco 
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Prerequisite A.5/23 - - UPDATE response 
Prerequisite: A.6/35 - - 485 (Ambiguous) 



Table A.160: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Contact 


[26] 20.10 


(note) 





[26] 20.10 


m 


m 


3 


Error-Info 


[26] 20.18 








[26] 20.18 








7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


NOTE: The strength of this requirement is RECOMMENDED rather than OPTIONAL. 



Prerequisite A.5/23 - - UPDATE response 

Table A. 161: Supported message bodies within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.2.2 Proxy role 
A.2.2.1 Introduction 

This subclause contains the ICS proforma tables related to the proxy role. They need to be completed only for proxy 
implementations. 

Prerequisite: A.2/2 - - proxy role 
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A.2.2.2 Major capabilities 



Table A.162: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC Status 


Profile status 




Capabilities within main protocol 








3 


initiate session release? 


[26] 16 


x 


c27 


4 


stateless proxy behaviour? 


[26] 16.11 


0.1 


c28 


5 


stateful proxy behaviour? 


[26] 16.2 


0.1 


c29 


6 


forl<ing of initial requests? 


[26] 16.1 


c1 


x 


7 


support of TLS connections on the 
upstream side? 


[26] 16.7 





n/a 


8 


support of TLS connections on the 

downstream side? 


[26] 16.7 





n/a 


8A 


authentication between UA and proxy? 


[26] 20.28, 
22.3 





X 


9 


insertion of date in requests and 
responses? 


[26] 20.17 








10 


91 innrpc;<^inn nr mnrlififfltinn f>f filprtinn 

OU|>y|.JiCOOivJii \J\ \ \ \ \J\Jll I\^CILIUI 1 \JI did III lU 

information data? 


[26] 20.4 


Q 


Q 


11 


reading the contents of the Require 
hparlpr hpfnrp nrnyvinn thp rpniipc;t nr 

response? 


[26] 20.32 








12 


adding or modifying the contents of the 
Require header before proxying the 

RP(^I^T"FR rpniiPQt nr rPQnnnQP 
ritvjaio 1 ic:?U|Uc:?oi ui icojjuiioc 


[26] 20.32 





m 


13 


adding or modifying the contents of the 
Rpmilrp hpadpr hpfnrp nrnxvinn thp 
request or response for methods other 
than REGISTER? 


[26] 20.32 








14 


hpinn phip tn in<^prt it*^plf in thp 

subsequent transactions in a dialog 
(record-routing)? 


[261 16 6 


Q 


c2 


15 


the requirement to be able to use 
^pnaratp IJRI^ in thp iin*?trpam HIrprtInn 

Owk./Cll CILC \J ■ IIO III LIIC LIUOLICdlll UIICOLI^II 

and downstream direction when record 
roufpinn'? 


[26] 16.7 


c3 


c3 


16 


reading the contents of the Supported 
header before proxying the response? 


[26] 20.37 








•|7 


rpprlinn thp rnntpntci of thp 
Unsupported header before proxying 
the 420 response to a REGISTER? 


[261 20 40 


Q 


m 


18 


rppfiinn thp rnntpntci of thp 
Unsupported header before proxying 
the 420 response to a method other 
than REGISTER? 


[261 20 40 


Q 


Q 


19 


the inclusion of the Error-Info header in 
3xx - 6xx responses? 


[26] 20.18 








19A 


rparlinn thp rnntpnt*? of thp 

1 ^CK^II 1^ 11 IC t.>t_/l lid no \Jl LI IC 

Organization header before proxying 
the request or response? 


[261 20 25 


Q 




19B 


aHHinn nr rrinrfltpnptinri thp 
Ornanization hpadpr bpforp Droxvinn 
the request or response? 


[261 20 25 


Q 


Q 


19C 


reading the contents of the Call-Info 
header before proxying the request or 
response? 


[26] 20.25 








19D 


adding or concatenating the Call-Info 
header before proxying the request or 

response? 


[26] 20.25 








19E 


delete Contact headers from 3xx 
responses prior to relaying the 
response? 


[26] 20 










Extensions 








20 


the SIP INFO method? 


[25] 








21 


reliability of provisional responses in 


[27] 





i 
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d-d. 


tne ribrbri metnour 


rod 

[36] 








23 


integration of resource management 
and SIP? 


[30] 







24 


the SIP UPDATE method? 


[29] 


c4 




26 


SIP extensions for media authorization? 


[31] 





c7 


27 


SIP specific event notification 


[28] 







28 


the use of NOTIFY to establish a dialog 


[28] 4.2 





n/a 


29 


Session Initiation Protocol Extension 
Header Field for Registering Non- 
Adjacent Contacts 


[35] 





c6 


30 


extensions to the Session Initiation 
Protocol (SIP) for asserted identity 
within trusted networks 


[34] 





m 


30A 


act as first entity within the trust domain 
for asserted identity 


[34] 


c5 


c8 


30B 


act as subsequent entity within trust 
network that can route outside the trust 

network 


[34] 


c5 


c9 


31 


a privacy mechanism for the Session 
Initiation Protocol (SIP) 


[33] 





m 


31A 


request of privacy by the inclusion of a 

Privacy header 


[33] 


n/a 


n/a 


31B 


application of privacy based on the 
received Privacy header 


[33] 


c10 


c12 


31C 


passing on of the Privacy header 
transparently 


[33] 


c10 


c13 


31 D 


application of the privacy option 
"header" such that those headers which 

cannot be completely expunged of 
identifying information without the 
assistance of intermediaries are 
obscured? 


[33] 5.1 


X 


X 


31E 


application of the privacy option 
"session" such that anonymization for 
the session(s) initiated by this message 
occurs? 


[33] 5.2 


n/a 


n/a 


31 F 


application of the privacy option "user" 
such that user level privacy functions 
are provided by the network? 


[33] 5.3 


n/a 


n/a 


31G 


application of the privacy option "id" 
such that privacy of the network 
asserted identity is provided by the 
network? 


[34] 7 


c11 


c12 


32 


Session Initiation Protocol Extension 
Header Field for Service Route 

Discovery During Registration 


[38] 





c30 


33 


a messaging mechanism for the 
Session Initiation Protocol (SIP) 


[50] 





m 


34 


Compressing the Session Initiation 
Protocol 


[55] 





c7 


35 


private header extensions to the 
session initiation protocol for the 3rd- 
Generation Partnership Project 
(3GPP)? 


[52] 





m 


36 


the P-Associated-URI header 
extension? 


[52] 4.1 


c14 


c15 


37 


the P-Called-Party-ID header 

extension? 


[52] 4.2 


c14 


c16 


38 


the P-Visited-Network-ID header 
extension? 


[52] 4.3 


c14 


c17 


39 


reading, or deleting the P-Visited- 
Network-ID header before proxying the 
request or response? 


[52] 4.3 


c18 


n/a 


41 


the P-Access-Network-lnfo header 

extension? 


[52] 4.4 


c14 


c19 


42 


act as first entity within the trust domain 


[52] 4.4 


c20 


c21 
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for access network information? 








43 


act as subsequent entity witliin trust 
networl< for access networl< information 
that can route outside the trust 
networl<? 


[52] 4.4 


c20 


c22 


44 


the P-Charging-Function-Addresses 
header extension? 


[52] 4.5 


c14 


m 


44A 


adding, deleting or reading the P- 
Charging-Function-Addresses header 
before proxying the request or 
response? 


[52] 4.6 


c25 


c26 


45 


the P-Charging-Vector header 

extension? 


[52] 4.6 


c14 


m 


46 


adding, deleting, reading or modifying 
the P-Charging-Vector header before 
proxying the request or response? 


[52] 4.6 


c23 


c24 


47 


security mechanism agreement for the 
session initiation protocol? 


[48] 





c7 
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c1 : IF A.162/5 THEN o ELSE n/a - - stateful proxy behaviour. 

C2: IF A.3/2 OR A.3/3A OR A.3/4 THEN m ELSE o - - P-CSCF, l-CSCF{THIG) or S-CSCF. 

C3: IF (A.162/7AND NOTA.162/8) OR (NOT A.1 62/7 AND A.1 62/8) THEN m ELSE IF 

A. 162/14 THEN o ELSE n/a - - TLS interworking with non-TLS else proxy insertion. 
c4: IF A. 162/23 THEN m ELSE o - - integration of resource management and SIP. 

c5: IF A.1 62/30 THEN o ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks. 
c6: IF A.3/2 OR A.3/3A THEN m ELSE n/a - - P-CSCF or l-CSCF (THIG). 

c7: IF A.3/2 THEN m ELSE n/a - - P-CSCF. 

c8: IF A.3/2 AND A.1 62/30 THEN m ELSE n/a - - P-CSCF and extensions to the Session 

Initiation Protocol (SIP) for asserted identity within trusted networks. 
C9: IF A.3/2 AND A.1 62/30 THEN m ELSE IF A.3/7C AND A.1 62/30 THEN o ELSE n/a - - 

S-GSGF or AS acting as proxy and extensions to the Session Initiation Protocol (SIP) 

for asserted identity within trusted networks (NOTE). 
clO: IF A. 162/31 THEN 0.2 ELSE n/a - - a privacy mechanism for the Session Initiation 

Protocol (SIP). 

c1 1 : IF A.1 62/31 B THEN o ELSE x - - application of privacy based on the received Privacy 
header. 

c12: IF A.1 62/31 AND A.3/4 THEN m ELSE n/a -- S-CSGF. 

c13: IF A.1 62/31 AND (A.3/2 OR A.3/3 OR A.3/7G) THEN m ELSE n/a - - P-GSGF OR I- 

GSGF OR AS acting as a SIP proxy. 
c14: IF A.1 62/35 THEN 0.3 ELSE n/a - - private header extensions to the session initiation 

protocol for the 3rd-Generation Partnership Project (3GPP). 
c15: IF A.1 62/35 AND (A.3/2 OR A.3/3) THEN m THEN o ELSE n/a - - private header 

extensions to the session initiation protocol for the 3rd-Generation Partnership Project 

(3GPP) and P-GSGF or l-GSGF. 
c1 6: IF A.1 62/35 AND (A.3/2 OR A.3/3 OR A.3/4) THEN m ELSE n/a - - private header 

extensions to the session initiation protocol for the 3rd-Generation Partnership Project 

(3GPP) and P-CSCF or l-CSCF or S-CSCF. 
c17: IF A.162/35 AND (A.3/2 OR A.3/3) THEN m ELSE n/a - - private header extensions to 

the session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and 

P-GSGF or l-GSGF. 

c18: IF A.1 62/38 THEN o ELSE n/a - - the P-Visited-Network-ID header extension. 
c1 9: IF A.1 62/35 AND (A.3/2 OR A.3.3 OR A.3/4 OR A.3/7 THEN m ELSE n/a - - private 
header extensions to the session initiation protocol for the 3rd-Generation Partnership 

Project (3GPP) and P-CSCF, l-GSGF, S-CSCF, AS acting as a proxy. 
c20: IF A.1 62/41 THEN o ELSE n/a - - the P-Access-Network-lnfo header extension. 
c21 : IF A.1 62/41 AND A.3/2 THEN m ELSE n/a - - the P-Access-Network-lnfo header 

extension and P-GSGF. 
c22: IF A.1 62/41 AND A.3/4 THEN m ELSE n/a - - the P-Access-Network-lnfo header 

extension and S-CSCF. 
c23: IF A.162/45 THEN o ELSE n/a - - the P-Charging-Vector header extension. 
c24: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 
c25: IF A. 162/44 THEN o ELSE n/a - - the P-Charging-Function-Addresses header 

extension. 

c26: IF A.1 62/44 THEN m ELSE n/a - - the P-Gharging-Function Addresses header 
extension. 

c27: IF A.3/2 OR A.3/4 THEN m ELSE x - - P-CSCF or S-CSGF. 

c28: IF A.3/2 OR A.3/4 OR A.3/6 then m ELSE o - - P-CSCF or S-CSCF of MGGF. 

c29: IF A.3/2 OR A.3/4 OR A.3/6 then o ELSE m - - P-GSGF or S-GSGF of MGGF. 

c30: IFA.3/2oELSEi-- P-CSCF. 

0.1 : It is mandatory to support at least one of these items. 

0.2: It is mandatory to support at least one of these items. 

0.3: It is mandatory to support at least one of these items. 

NOTE: An AS acting as a proxy may be outside the trust domain, and therefore not able to 

support the capability for that reason; in this case it is perfectly reasonable for the 
header to be passed on transparently, as specified in the PDU parts of the profile. 
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A.2.2.3 PDUs 



Table A.163: Supported methods 



Item 


PDU 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


ACK request 


[26] 13 


m 


m 


[26] 13 


m 


m 


2 


BYE request 


[26] 1 6 


m 


m 


[26] 16 


m 


m 


3 


BYE response 


[26] 16 


m 


m 


[26] 16 


m 


m 


4 


CANCEL request 


[26] 16.10 


m 


m 


[26] 16.10 


m 


m 


5 


CANCEL response 


[26] 16.10 


m 


m 


[26] 16.10 


m 


m 


8 


INVITE request 


[26] 16 


m 


m 


[26] 16 


m 


m 


9 


INVITE response 


[26] 16 


m 


m 


[26] 16 


m 


m 


9A 


MESSAGE request 


[50] 4 


c5 


c5 


[50] 7 


c5 


c5 


9B 


MESSAGE response 


[50] 4 


c5 


c5 


[50] 7 


c5 


c5 


10 


NOTIFY request 


[28] 8.1.2 


c3 


c3 


[28] 8.1.2 


c3 


c3 


11 


NOTIFY response 


[28] 8.1.2 


c3 


c3 


[28] 8.1.2 


c3 


c3 


12 


OPTIONS request 


[26] 16 


m 


m 


[26] 16 


m 


m 


13 


OPTIONS response 


[26] 16 


m 


m 


[26] 16 


m 


m 


14 


PRACK request 


[2716 


c6 


c6 


[27] 6 


c6 


c6 


15 


PRACK response 


[27] 6 


c6 


c6 


[27] 6 


c6 


c6 


16 


REFER request 


[36] 3 


Cl 


cl 


[36] 3 


cl 


cl 


17 


REFER response 


[36] 3 


Cl 


cl 


[36] 3 


c1 


cl 


18 


REGISTER request 


[26] 16 


m 


m 


[26] 16 


m 


m 


19 


REGISTER response 


[26] 16 


m 


m 


[26] 16 


m 


m 


20 


SUBSCRIBE request 


[28] 8.1.1 


c3 


c3 


[28] 8.1.1 


c3 


c3 


21 


SUBSCRIBE response 


[28] 8.1.1 


c3 


c3 


[28] 8.1.1 


c3 


c3 


22 


UPDATE request 


[30] 7 


c4 


c4 


[30] 7 


c4 


c4 


23 


UPDATE response 


[30] 7 


c4 


c4 


[30] 7 


c4 


c4 


c1: 


IF A.I 62/22 THEN m ELSE n/a 


- the REFER method. 










C3 


IF A.I 62/27 THEN m ELSE n/a 


- - SIP specific event notification. 








c4 


IF A.I 62/24 THEN m ELSE n/a 


■ - the SIP UPDATE method. 








c5: 


IF A.I 62/33 THEN m ELSE n/a 


- the SIP MESSAGE method. 








c6: 


If A.1 62/21 THEN m ELSE n/a 


- - reliability of provisional responses. 
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A.2.2.4 PDU parameters 
A.2.2.4.1 Status-codes 



Table A.164: Supported-status codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


100 (Trying) 


[26] 
21.1.1 


Cl 


cl 


[26] 
21.1.1 


c2 


c2 


2 


180 (Ringing) 


[26] 
21.1.2 


c3 


c3 


[26] 
21.1.2 


c3 


c3 


3 


181 (Call Is Being Forwarded) 


[26] 
21.1.3 


c3 


c3 


[26] 
21.1.3 


c3 


c3 


4 


182 (Queued) 


[26] 
21.1.4 


c3 


c3 


[26] 
21.1.4 


c3 


c3 


5 


183 (Session Progress) 


[26] 
21.1.5 


c3 


c3 


[26] 
21.1.5 


c3 


c3 


6 


200 (OK) 


[26] 
21.2.1 






[26] 
21.2.1 






7 


202 (Accepted) 


[28] 8.3.1 


c4 


c4 


[28] 8.3.1 


c4 


c4 


8 


300 (Multiple Choices) 


[26] 
21.3.1 






[26] 
21.3.1 






9 


301 (Moved Permanently) 


[26] 
21.3.2 






[26] 
21.3.2 






10 


302 (Moved Temporarily) 


[26] 
21.3.3 






[26] 
21.3.3 






11 


305 (Use Proxy) 


[26] 
21.3.4 






[26] 
21.3.4 






12 


380 (Alternative Service) 


[26] 
21.3.5 






[26] 

21.3.5 






13 


400 (Bad Request) 


[26] 
21.4.1 






[26] 
21.4.1 






14 


401 (Unauthorized) 


[26] 
21.4.2 






[26] 
21.4.2 






15 


402 (Payment Required) 


[26] 
21.4.3 






[26] 
21.4.3 






16 


403 (Forbidden) 


[26] 
21.4.4 






[26] 
21.4.4 






17 


404 (Not Found) 


[26] 
21.4.5 






[26] 
21.4.5 






18 


405 (Method Not Allowed) 


[26] 
21.4.6 






[26] 
21.4.6 






19 


406 (Not Acceptable) 


[26] 
21.4.7 






[26] 
21.4.7 






20 


407 (Proxy Authentication 
Required) 


[26] 
21.4.8 






[26] 
21.4.8 






21 


408 (Request Timeout) 


[26] 
21.4.9 






[26] 
21.4.9 






22 


410 (Gone) 


[26] 

21.4.10 






[26] 

21.4.10 






23 


413 (Request Entity Too 

Large) 


[26] 
21.4.11 






[26] 
21.4.11 






24 


414 (Request-URI Too Large) 


[26] 

21.4.12 






[26] 

21.4.12 






25 


415 (Unsupported Media 
Type) 


[26] 

21.4.13 






[26] 

21.4.13 






26 


416 (Unsupported URI 
Scheme) 


[26] 

21.4.14 






[26] 

21.4.14 






27 


420 (Bad Extension) 


[26] 

21.4.15 






[26] 

21.4.15 






28 


421 (Extension Required) 


[26] 

21.4.16 






[26] 

21.4.16 






29 


423 (Interval Too Brief) 


[26] 

21.4.17 


c5 


c5 


[26] 

21.4.17 


c6 


c6 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


30 


480 (Temporarily not 
available) 


[26] 

21.4.18 






[26] 

21.4.18 






31 


481 (Call /Transaction Does 
Not Exist) 


[26] 

21.4.19 






[26] 

21.4.19 






32 


482 (Loop Detected) 


[26] 

21.4.20 






[26] 

21.4.20 






33 


483 (Too Many Hops) 


[26] 
21.4.21 






[26] 
21.4.21 






34 


484 (Address Incomplete) 


[26] 

21.4.22 






[26] 

21.4.22 






35 


485 (Ambiguous) 


[26] 

21.4.23 






[26] 

21.4.23 






36 


486 (Busy Here) 


[26] 

21.4.24 






[26] 

21.4.24 






37 


487 (Request Terminated) 


[26] 

21 .4.25 






[26] 

21 .4.25 






38 


488 (Not Acceptable Here) 


[26] 

21.4.26 






[26] 

21.4.26 






39 


489 (Bad Event) 


[28] 7.3.2 


c4 


c4 


[28] 7.3.2 


c4 


c4 


40 


491 (Request Pending) 


[26] 

21.4.27 






[26] 

21.4.27 






41 


493 (Undecipherable) 


[26] 

21.4.28 






[26] 

21.4.28 






41 A 


494 (Security Agreement 
Required) 


[48] 2 


c7 


c7 


[48] 2 


n/a 


n/a 


42 


500 (Internal Server Error) 


[26] 
21.5.1 






[26] 
21.5.1 






43 


501 (Not Implemented) 


[26] 
21.5.2 






[26] 
21.5.2 






44 


502 (Bad Gateway) 


[26] 
21.5.3 






[26] 
21.5.3 






45 


503 (Service Unavailable) 


[26] 
21 .5.4 






[26] 
21.5.4 






46 


504 (Server Time-out) 


[26] 
21.5.5 






[26] 
21.5.5 






47 


505 (Version not supported) 


[26] 
21.5.6 






[26] 
21.5.6 






48 


513 (Message Too Large) 


[26] 
21 .5.7 






[26] 
21 .5.7 






49 


580 (Precondition Failure) 


[30] 8 






[30] 8 






50 


600 (Busy Everywhere) 


[26] 
21.6.1 






[26] 
21.6.1 






51 


603 (Decline) 


[26] 
21.6.2 






[26] 
21.6.2 






52 


604 (Does Not Exist 
Anywhere) 


[26] 
21.6.3 






[26] 
21.6.3 






53 


606 (Not Acceptable) 


[26] 
21.6.4 






[26] 
21.6.4 







c1: IF A.I 62/1 5 THEN m ELSE n/a - - stateful proxy. 

c2: IF A.162/15 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 



and downstream direction when record routeing. 
c3: IF A.I 63/9 THEN m ELSE n/a - - INVITE response. 

c4: IF A.I 62/27 THEN m ELSE n/a - - SIP specific event notification. 

c5: IF A.I 63/1 9 OR A.I 63/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE response. 

c6: IF A.163/19 OR A.163/21 THEN i ELSE n/a - - REGISTER response or SUBSCRIBE response. 

c7: IF A.I 62/47 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 
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A.2.2.4.2 ACK method 

Prerequisite A. 163/1 - - ACK request 



Table A.165: Supported headers within the ACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


Cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


7 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


8 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


9 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


10 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


1 1 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


12 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


13 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


14 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


15 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


16 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


17 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


17A 


Privacy 


[33] 4.2 


c6 


c6 


[33] 4.2 


c7 


c7 


18 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


19 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


20 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


21 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


22 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


23 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



cl : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.I 62/1 1 OR A.1 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying 



the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A.162/31D OR A.1 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 

SUBSCRIBE and NOTIFY. 



Editor's note: Is the following table a suitable way of showing the contents of message bodies. 
Prerequisite A. 163/1 - - ACK request 



Table A.1 66: Supported message bodies within the ACK request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.3 BYE method 

Prerequisite A. 163/2 - - BYE request 



Table A.I 67: Supported headers within the BYE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 




3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 




4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


c3 


8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c3 


9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c3 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


16 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


16B 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[34] 9.1 


clO 


clO 


16C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c17 


c17 


[52] 4.5 


CIS 


c18 


16D 


P-Charging-Vector 


[52] 4.6 


c15 


n/a 


[52] 4.6 


c16 


n/a 


16E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c8 


n/a 


16F 


Privacy 


[33] 4.2 


oil 


c11 


[33] 4.2 


c12 


c12 


17 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


18 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


19 


Record-Route 


[26] 20.30 


nn 


m 


[26] 20.30 


c7 


c7 


20 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


21 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


21A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c19 


c19 


21 B 


Security- Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c19 


c19 


22 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


23 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


24 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


25 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


26 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

c8; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c9: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c10: IF A.162/30Aor A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 1 : IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c12: IF A.1 62/31 DOR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a -- application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.1 62/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c1 5: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c16: IF A. 162/46 THEN m ELSE IF A. 162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 

c17: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c1 8: IF A.1 62/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c19: IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/2 - - BYE request 



Table A.1 68: Supported message bodies within the BYE request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A. 163/3 - - BYE response 
Prerequisite: A.164/1 - - 100 (Trying) 



Table A.1 69: Supported headers within the BYE response 



item 


IHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 
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Prerequisite A. 163/3 - - BYE response 



Table A.170: Supported headers within the BYE response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


d. 


Content- Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


c2 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c2 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c2 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c2 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


c1 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c2 


10A 


P-Access-Networl<-lnfo 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


10B 


P-Asserted-ldentity 


[34] 9.1 


c4 


c4 


[34] 9.1 


c5 


c5 


IOC 


P-Charging-Function- 
Addresses 


[52] 4.5 


clO 


clO 


[52] 4.5 


c1 1 


c1 1 


10D 


P-Charging-Vector 


[52] 4.6 


c8 


n/a 


[52] 4.6 


c9 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10F 


Privacy 


[33] 4.2 


c6 


c6 


[33] 4.2 


c7 


c7 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


10H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c3: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 



c5: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c6: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A.I 62/310 OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 

extension. 

clO: IF A.162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c1 1 : IF A.I 62/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c12: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c14: IF A.162/11 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 



Prerequisite A. 163/3 - - BYE response 
Prerequisite: A. 164/6 - - 2xx 

Table A.171 : Supported headers within the BYE response 
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Item 


Header 


Sending 


Receiving 


Ret. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: IF A.1 62/1 5 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/3 - BYE response 

Prerequisite: A. 164/8 OR A. 164/9 OR A. 164/10 OR A. 164/1 1 OR A. 164/12 OR A. 164/35 - - 3xx or 485 (Ambiguous) 
Table A.1 72: Supported headers within the BYE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1: 


IF A.1 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/3 - - BYE response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 

Tabie A.1 73: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

status 


Profile 

status 


Ref. 


RFC 

status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


1 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 

Table A.1 74: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/3 - - BYE response 

Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.175: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 



Table A.176: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/3 - - BYE response 

Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 



Table A.177: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[261 20.2 


m 


m 


[261 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/3 - - BYE response 
Prerequisite: A.164/27 - - 420 (Bad Extension) 



Table A.178: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


















4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/3 - - BYE response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.178A: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A. 163/3 - - BYE response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.1 79: Supported headers within the BYE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/3 - - BYE response 



Table A.1 80: Supported message bodies within the BYE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.4 CANCEL method 

Prerequisite A. 163/4 - - CANCEL request 



Table A.I 81 : Supported headers within the CANCEL request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


9 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


10 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


12 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


13 


Privacy 


[33] 4.2 


c3 


c3 


[33] 4.2 


c4 


c4 


16 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


18 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


19 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


20 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


21 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


22 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


23 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



cl : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A. 162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c4: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 



option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c6: IF A.I 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

NOTE: cl refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/4 - - CANCEL request 



Table A.182: Supported message bodies within the CANCEL request 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/5 - - CANCEL response 



Table A.183: Supported headers within the CANCEL response - all status-codes 



Item 


IHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


Cl 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


5A 


Privacy 


[33] 4.2 


c2 


c2 


[33] 4.2 


c3 


c3 


6 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


7 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7A 


User-Agent 


[26] 20.41 







[26] 20.41 







8 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


9 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c3: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 



option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 

Prerequisite A. 163/5 - - CANCEL response 
Prerequisite: A. 164/6 - - 200 (OK) 



Table A.1 84: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: IF A.1 62/1 5 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/5 - - CANCEL response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 



Table A.185: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



Prerequisite A. 163/5 - - CANCEL response 

Prerequisite: A. 164/17 OR A.164/23 OR A.164/30 OR A.164/42 OR A.164/45 OR A.164/50 OR A.164/51 - - 404, 413, 
480, 500, 503, 600, 603 



Table A.1 86: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


2 


Error-Info 


[26] 2418 


m 


m 


[26] 20.18 






4 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/5 - - CANCEL response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 



Table A.188: Supported headers within the CANCEL response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



Prerequisite A. 163/5 - - CANCEL response 



Table A.189: Supported message bodies within the CANCEL response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.5 COMET method 

Void 

A.2.2.4.6 INFO method 

Void 

A.2.2.4.7 INVITE method 

Prerequisite A. 163/8 - - INVITE request 



Table A.204: Supported headers within the INVITE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


4 


Alert-Info 


[26] 20.4 


c2 


c2 


[26] 20.4 


c3 


c3 


5 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


6 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


8 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


9 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


10 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c12 


c12 


11 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


12 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


c6 


13 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c6 


14 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c6 


15 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


16 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c6 


17 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


18 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c4 


c4 


19 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


20 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


21 


In-Reply-To 


[26] 20.21 


m 


m 


[26] 20.21 


i 


i 


22 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


23 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c6 


24 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c5 


c5 


24A 


P-Access-Network-lnfo 


[52] 4.4 


c28 


c28 


[52] 4.4 


c29 


c30 


24B 


P-Asserted-ldentity 


[34] 9.1 


c15 


c15 


[34] 9.1 


c16 


c16 


24C 


P-Called-Party-ID 


[52] 4.2 


c19 


c19 


[52] 4.2 


c20 


c21 


24D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c26 


c27 


[52] 4.5 


c26 


c27 


24E 


P-Charging-Vector 


[52] 4.6 


c24 


c24 


[52] 4.6 


c25 


c25 


25 


P-Media-Authorization 


[31] 6.1 


C9 


clO 


[31] 6.1 


n/a 


n/a 


25A 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c14 


c14 


25B 


P-Visited-Network-ID 


[52] 4.3 


c22 


n/a 


[52] 4.3 


c23 


n/a 


26 


Priority 


[26] 20.26 


m 


m 


[26] 20.26 


i 


i 


26A 


Privacy 


[33] 4.2 


c17 


c17 


[33] 4.2 


c18 


c18 


27 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c13 


c13 


28 


Proxy- Require 


[26] 
20.29, 
[34] 4 


m 


m 


[26] 
20.29, 
[34] 4 


m 


m 


29 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c11 


c11 


31 


Reply-To 


[26] 20.31 


m 


m 


[26] 20.31 


i 


i 


32 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c7 


c7 


33 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


33A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c31 


c31 


33B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c31 


c31 


34 


Subject 


[26] 20.36 


m 


m 


[26] 20.36 


i 


i 


35 


Supported 


[26] 20.37 


rr\ 


m 


[26] 20.37 


c8 


c8 


36 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 
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Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profiie 
status 


Ref. 


RFC 
Status 


Profile 
status 


37 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


38 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


39 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



c1 : IF A. 4/20 THEN m ELSE 1 - - SIP specific event notification extension. 

c2: IF A.162/10 THEN n/a ELSE m - - suppression or modification of alerting information data. 

c3: IF A.162/10 THEN m ELSE i - - suppression or modification of alerting information data. 

c4: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c5: IF A.I 62/1 9A OR A.I 62/1 9B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c6: IF A.3/2 OR A.3/4 THEN m ELSE I - - P-CSCF or S-CSCF. 

c7: IF A.I 62/1 1 OR A.I 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c8: IF A. 162/16 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c9: IF A.I 62/26 THEN m ELSE n/a - - SIP extensions for media authorization. 

c1 0: IF A.3/2 THEN m ELSE n/a - - P-CSCF. 

c1 1 : IF A.162/14 THEN m ELSE I - - the requirement to be able to Insert Itself In the subsequent transactions In 

a dialog. 

c12: IF A. 162/190 OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 
c13: IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

c14: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted Identity. 
c1 5: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted Identity 
within trusted networks. 

c16: IF A.162/30Aor A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c17: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c18: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN I ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "Id" or passing on of the Privacy header transparently. 
c1 9: IF A.I 62/37 THEN m ELSE n/a - - the P-Cal led- Party- ID header extension. 
c20: IF A.I 62/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c21: IF A.I 62/37 AND A.3/2 THEN m ELSE IF A.I 62/37 AND A.3/3 THEN i ELSE n/a -- the P-Called-Party-lD 

header extension and P-CSCF or l-CSCF. 
c22: IF A.I 62/38 THEN m ELSE n/a - - the P-Vislted-Network-ID header extension. 

c23: IF A.I 62/39 THEN m ELSE I - - reading, or deleting the P-Vlslted-Network-ID header before proxying the 
request or response. 

c24: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c25: IF A. 162/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a -- adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c26: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Functlon-Addresses header extension. 
c27: IF A.I 62/44A THEN m ELSE IF A.I 62/44 THEN I ELSE n/a - - adding, deleting or reading the P-Charglng- 
Functlon-Addresses header before proxying the request or response, or the P-Charglng-Functlon- 

Addresses header extension. 

c28: IF A. 162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c29: IF A.I 62/43 THEN m ELSE IF A.I 62/41 THEN I ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c30: IF A.I 62/43 OR (A.162/41 AND A.3/2) THEN m ELSE IF A.162/41 THEN I ELSE n/a - - act as subsequent 
entity within trust network for access network information that can route outside the trust network, the P- 
Access-Network-lnfo header extension (with or without P-CSCF). 

c31 : IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session Initiation protocol. 

NOTE: c1 refers to the UA role major capability as this Is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Prerequisite A. 163/8 - - INVITE request 



Table A.205: Supported message bodies within the INVITE request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A.164/1 - - 100 (Trying) 



Table A.206: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Gseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


Cl 


cl 


[26] 20.17 


c2 


c2 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF (A. 162/9 AND A. 162/5) OR A. 162/4 THEN m ELSE n/a 


- - stateful proxy behaviour that inserts date, or 


c2: 


stateless proxies. 

IF A.I 62/4 THEN 1 ELSE m - - Stateless proxy passes on. 
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Prerequisite A. 163/9 - - INVITE response 



Table A.207: Supported headers within the INVITE response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


uail-lnto 


[26J 20.9 


m 


m 


[26] 20.9 


c4 


c4 


2 


Content- Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


c3 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c3 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c3 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


1 1 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


1 1 A 


P-Access-Networl<-lnfo 


[52] 4.4 


c14 


c14 


[52] 4.4 


c15 


c15 


1 1 B 


P-Asserted-ldentity 


[34] 9.1 


c6 


c6 


[34] 9.1 


c7 


c7 


11C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c12 


c12 


[52] 4.5 


c13 


c13 


11D 


P-Chiarging-Vector 


[52] 4.6 


clO 


clO 


[52] 4.6 


c11 


c11 


11E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c5 


n/a 


11F 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c9 


c9 


11G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c16 


c16 


11H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 



c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c6: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c7: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c8: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c9: IF A.I 62/31 DOR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently, 
cl 0: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c11: IF A. 162/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a -- adding, deleting, reading or modifying the P- 
Gharging-Vector header before proxying the request or response or the P-Oharging-Vector header 
extension. 

c12: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

CIS: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c14: IF A.1 62/43 THEN x ELSE IF A.1 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c15: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c16: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 
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Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/2 OR A. 164/3 OR A. 164/4 OR A. 164/5 - - Ixx 

Table A.208: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


1 


i 


6 


P-Media-Authorization 


[31] 6.1 


c9 


clO 


[31] 6.1 


n/a 


n/a 


9 


Rseq 


[27] 7.1 


m 


m 


[27] 7.1 


1 


i 


11 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


1 


i 


c9: IF A.I 62/26 THEN m ELSE n/a - - SIP extensions for media authorization. 
c1 0: IF A.3/2 THEN m ELSE n/a - - P-CSCF. 



Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A. 164/6 - - 2xx 



Table A.209: Supported headers within the INVITE response 



Item 



Header 



Ref. 



Sending 



RFC 
status 



Profile 
status 



Ref. 



Receiving 



RFC 
status 



Profile 
status 



Accept 



[26] 20.1 



m 



m 



[26] 20.1 



1A 



Accept-Encoding 



[26] 20.2 



m 



m 



[26] 20.2 



IB 



Accept-Language 



[26] 20.3 



m 



m 



[26] 20.3 



Allow 



[26] 20.5 



m 



m 



[26] 20.5 



Authentication-Info 



[26] 20.6 



m 



m 



[26] 20.6 



Contact 



[26] 20.10 



m 



m 



[26] 20.10 



P-Media-Authorization 



[31] 6.1 



c9 



clO 



[31] 6.1 



n/a 



n/a 



Record-Route 



[26] 20.30 



m 



m 



[26] 20.30 



c3 



c3 



13 



Supported 



[26] 20.37 



m 



m 



[26] 20.37 



c3: IF A.1 62/1 4 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 

c9: IF A.I 62/26 THEN m ELSE n/a - - SIP extensions for media authorization. 

c1 0: IF A.3/2 THEN m ELSE n/a - - P-GSCF. 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/11 OR A.164/12 OR A.164/35 - - 3xx or 485 (Ambiguous) 
Table A.210: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


C1 


5 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1: 


IF A.I 62/1 9E THEN m ELSE 1 - 


- deleting Contact headers. 
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Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 



Table A.21 1 : Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


6 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


15 


www-Authenticate 


[26] 20.44 







[26] 20.44 








Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/50 OR A.164/51 - - 404, 413, 480, 486, 
600, 603 

Table A.21 2: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






12 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A. 164/18 - - 405 (Method Not Allowed) 

Table A.21 3: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 




[26] 20.5 


m/o 




5 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


13 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 

Table A.21 4: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

status 


Profile 
status 


Ref. 


RFC 

status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


6 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


11 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 
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Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 



Table A.215: Supported headers within the INVITE response 



Item 


hHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






6 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






11 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A.164/27 - - 420 (Bad Extension) 



Table A.216: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






10 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE 1 - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 



Prerequisite A. 163/9 - - INVITE response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.216A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 

Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


Cl 


[481 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.I 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 



Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 



Table A.217: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






g 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A.164/42 - - 500 (Server Internal Error) 



Table A.217A: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/9 - - INVITE response 
Prerequisite: A.164/45 - - 503 (Service Unavailable) 

Table A.217B: Supported headers within the INVITE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






8 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/9 - - INVITE response 

Table A.218: Supported message bodies within the INVITE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















ETSI 



3GPP TS 24.229 version 5.11 .1 Release 5 1 88 ETSI TS 1 24 229 V5.1 1 .1 (2005-01 ) 

A.2.2.4.7A MESSAGE method 

Prerequisite A. 163/9 A - - MESSAGE request 



Table A.218A: Supported headers within the MESSAGE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[50] 1 


i 


i 


2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


6 


Content-Disposition 


[26] 20. 11 


m 


m 


[26] 20.1 1 


i 


i 


7 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


8 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


9 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


10 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


11 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


12 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


13 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


1 


i 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


In-Reply-To 


[26] 20.21 


m 


m 


[50] 10 


i 


i 


16 


Max-Fonwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


17 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


18 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


18A 


P-Access-Network-lnfo 


[52] 4.4 


c23 


c23 


[52] 4.4 


C24 


c24 


18B 


P-Asserted-ldentity 


[34] 9.1 


clO 


clO 


[34] 9.1 


c11 


c11 


18C 


P-Called-Party-ID 


[52] 4.2 


c14 


c14 


[52] 4.2 


c15 


c16 


18D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c21 


c21 


[52] 4.5 


c22 


c22 


18E 


P-Charging-Vector 


[52] 4.6 


c19 


c19 


[52] 4.6 


c20 


c20 


18F 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c9 


c9 


18G 


P-Visited-Network-ID 


[52] 4.3 


c17 


n/a 


[52] 4.3 


c18 


n/a 


19 


Priority 


[26] 20.26 


m 


m 


[26] 20.26 


i 


i 


19A 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c13 


c13 


20 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c8 


c8 


21 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


22 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


23 


Reply-To 


[26] 20.31 


m 


m 


[26] 20.31 


i 


i 


24 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


25A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


25B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


26 


Subject 


[26] 20.36 


m 


m 


[26] 20.36 






27 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


28 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 






29 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


30 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 






31 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A. 162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE 1 - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A. 1 62/1 6 THEN m ELSE I - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE I - - the requirement to be able to Insert Itself In the subsequent transactions In a 

dialog. 

c8: IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

c9: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted Identity. 

clO: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted Identity 
within trusted networks. 

c1 1 : IF A.162/30A or A.162/30B THEN m ELSE I - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c12: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c13: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN 1 ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "Id" or passing on of the Privacy header transparently. 
c14: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c15: IF A.162/37 THEN 1 ELSE n/a - - the P-Called-Party-ID header extension. 

c16: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN I ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c1 7: IF A.I 62/38 THEN m ELSE n/a - - the P-Vlslted-Network-ID header extension. 

c1 8: IF A.I 62/39 THEN m ELSE I - - reading, or deleting the P-Vlslted-Network-ID header before proxying the 
request or response. 

c19: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c20: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN I ELSE n/a - - adding, deleting, reading or modifying the P- 
Charglng-Vector header before proxying the request or response or the P-Charglng-Vector header 
extension. 

c21 : IF A.I 62/44 THEN m ELSE n/a - - the P-Charglng-Functlon-Addresses header extension. 

c22: IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charglng- 

Functlon-Addresses header before proxying the request or response, or the P-Charging-Functlon- 

Addresses header extension. 

c23: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c24: IF A.162/43 THEN m ELSE IF A.162/41 THEN I ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c25: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/9 A - - MESSAGE request 



Table A.218B: Supported message bodies within tlie lUlESSAGE request 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A.163/9B - - MESSAGE response 



Table A.218C: Supported headers within the lUlESSAGE response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


d. 


uail-lnto 


[26J 20.9 


m 


m 


[26] 20.9 


c3 


c3 


3 


Content- Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


1 


4 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


5 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


6 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


Cl 


10 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


1 1 


MIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


12 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


12A 


P-Access-Networl<-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


12B 


P-Asserted-ldentity 


[34] 9.1 


c5 


c5 


[34] 9.1 


c6 


c6 


12C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c1 1 


c1 1 


[52] 4.5 


c12 


c12 


12D 


P-Chiarging-Vector 


[52] 4.6 


c9 


n/a 


[52] 4.6 


clO 


n/a 


12E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c4 


n/a 


12F 


Privacy 


[33] 4.2 


c7 


c7 


[33] 4.2 


c8 


c8 


12G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c15 


c15 


13 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


14 


Timestamp 


[26] 20.38 


i 


i 


[26] 20.38 


i 


i 


15 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


16 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


17 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


18 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.I 62/1 9A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 



c3: IF A.I 62/1 9C OR A.I 62/1 9D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c4: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c5: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c6: IF A.162/30Aor A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c7: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c8: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c9: IF A. 162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

clO: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

cl 1 : IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c12: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Gharging-Function- 

Addresses header extension. 

CIS: IF A.I 62/43 THEN x ELSE IF A.1 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c15: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 
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Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A. 164/6 - - 2xx 



Table A.218D: Supported headers within the lUlESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


4 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: 


IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/8 OR A. 164/9 OR A. 164/10 OR A. 164/11 OR A. 164/12 OR A. 164/35 - - 3xx or 485 (Ambiguous) 
Table A.218E: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[50] 10 


i 


i 


2 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


c1 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1: 


IF A.1 62/1 9E THEN m ELSE 1 - 


- deleting Contact headers. 









Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 

Table A.218F: Supported headers within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[50] 10 


1 


i 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


1 


i 


6 


WWW-Authentlcate 


[26] 20.44 


m 


m 


[26] 20.44 


1 


i 



Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 

Table A.218G: Supported headers within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[50] 10 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.218H: Supported headers within the lUlESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 

Table A.218I: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[50] 10 


i 


i 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 

Table A.218J: Supported headers within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[261 20.2 


m 


m 


[261 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






4 


Allow 


[26] 20.5 


m 


m 


[50] 10 






5 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A.164/27 - - 420 (Bad Extension) 

Table A.218K: Supported headers within the lUIESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[50] 10 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: 


IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A.163/9B - - MESSAGE response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.218L: Supported headers within the lUlESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A.163/9B - - MESSAGE response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.218IUI: Supported headers within the MESSAGE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[50] 10 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A.163/9B - - MESSAGE response 



Table A.218N: Supported message bodies within the MESSAGE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.8 NOTIFY method 

Prerequisite A. 163/10 - - NOTIFY request 



Table A.219: Supported headers within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


10 


Content-Length 


[26] 20.14 


nn 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


16 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


17 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


17A 


P-Access-Network-lnfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


17B 


P-Asserted-ldentity 


[34] 9.1 


c8 


c8 


[34] 9.1 


c9 


c9 


17C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


17D 


P-Charging-Vector 


[52] 4.6 


c12 


n/a 


[52] 4.6 


c13 


n/a 


17E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


17F 


Privacy 


[33] 4.2 


clO 


clO 


[33] 4.2 


c11 


c11 


18 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


19 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


20 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


21 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


22A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


22B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


23 


Subscription-State 


[28] 8.2.3 


m 


m 


[28] 8.2.3 




i 


24 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


25 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 




i 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 




i 


28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 162/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14THEN (IF A.162/22 OR A.I 62/27 THEN m ELSE o) ELSE 1 - - the requirement to be able to 

insert itself in the subsequent transactions in a dialog or (the REFER method or SIP specific event 
notification). 

c8: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c9: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 0: IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c11: IF A.1 62/31 D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c12: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A. 162/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c14: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c1 5: IF A.1 62/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c16: IF A. 162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c1 7: IF A.1 62/43 THEN m ELSE IF A.1 62/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c18: IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/10 - - NOTIFY request 



Table A.220: Supported message bodies within the NOTIFY request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


sipfrag 


[37] 2 


m 


m 


[37] 2 


i 


i 
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Prerequisite A. 163/11 - - NOTIFY response 



Table A.221 : Supported headers within the NOTIFY response - all status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


d. 


Content- Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


c1 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10A 


P-Access-Networl<-lnfo 


[52] 4.4 


c1 1 


c1 1 


[52] 4.4 


c12 


c12 


10B 


P-Asserted-ldentity 


[34] 9.1 


c3 


c3 


[34] 9.1 


c4 


c4 


IOC 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


c9 


[52] 4.5 


clO 


clO 


10D 


P-Charging-Vector 


[52] 4.6 


c7 


n/a 


[52] 4.6 


c8 


n/a 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c2 


n/a 


10F 


Privacy 


[33] 4.2 


c5 


c5 


[33] 4.2 


c6 


c6 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c13 


c13 


10H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



c1 : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c3: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 



c4: IF A.162/30A or A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c5: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c6: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c7: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c8: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c9: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

ClO: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c11: IF A.I 62/43 THEN x ELSE IF A.I 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c12: IF A.I 62/43 THEN m ELSE IF A.I 62/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 



Prerequisite A. 163/11 - - NOTIFY response 
Prerequisite: A.164/6 AND A.164/7 - - 2xx 

Table A.222: Supported headers within the NOTIFY response 



Item I Header | Sending | Receivirig 
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rfei. 


Status 


Profile 
status 


rfei. 


Status 


Profile 
status 


UA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


2 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: 


IF A.1 62/1 5 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/1 1 - - NOTIFY response 

Prerequisite: A. 164/8 OR A. 164/9 OR A. 164/10 OR A. 164/1 1 OR A. 164/12 OR A. 164/35 - - 3xx or 485 (Ambiguous) 
Table A.223: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
Status 


Ref. 


RFC 
Status 


Profile 
Status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/11 - - NOTIFY response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 

Table A.224: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

status 


Profile 

status 


Ref. 


RFC 

status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 

Table A.225: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
Status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/11 - - NOTIFY response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.226: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 



Table A.227: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/1 1 - - NOTIFY response 
Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 

Table A.228: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[261 20.2 


m 


m 


[261 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/11 - - NOTIFY response 
Prerequisite: A.164/27 - - 420 (Bad Extension) 

Table A.229: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/11 - - NOTIFY response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.229A: Supported headers within the NOTIFY response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A. 163/1 1 - - NOTIFY response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.230: Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/1 1 - - NOTIFY response 
Prerequisite: A.164/39 - - 489 (Bad Event) 

Table A.231 : Supported headers within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


c1: 


IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 








NOTE: 


c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/11 - - NOTIFY response 

Table A.232: Supported message bodies within the NOTIFY response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.9 OPTIONS method 

Prerequisite A. 163/12 - - OPTIONS request 



Table A.233: Supported headers within the OPTIONS request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 




3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 




4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c4 


c4 


8 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 




9 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


-! 


10 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 




11 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


12 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


18 


IVIII^E-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


19 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


19A 


P-Access-Networl<-lnfo 


[52] 4.4 


c23 


c23 


[52] 4.4 


c24 


c24 


19B 


P-Asserted-ldentity 


[34] 9.1 


c10 


clO 


[34] 9.1 


c11 


c11 


19C 


P-Called-Party-ID 


[52] 4.2 


c14 


c14 


[52] 4.2 


c15 


c16 


19D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c21 


c21 


[52] 4.5 


c22 


c22 


19E 


P-Charging-Vector 


[52] 4.6 


c19 


c19 


[52] 4.6 


c20 


c20 


19F 


P-Preferred-ldentity 


[34] 9.2 


x 


X 


[34] 9.2 


c9 


c9 


19G 


P-Visited-Network-ID 


[52] 4.3 


c17 


n/a 


[52] 4.3 


c18 


n/a 


19H 


Privacy 


[33] 4.2 


c12 


c12 


[33] 4.2 


c13 


c13 


20 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c8 


c8 


21 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


22 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


23 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


24A 


Security-Client 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c25 


c25 


24B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c25 


c25 


25 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


26 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 



ETSI 



3GPP TS 24.229 version 5.11.1 Release 5 



201 



ETSI TS 124 229 V5.11.1 (2005-01) 



c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A. 162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE 1 - - reading, adding or concatenating the Call-Info header. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c6: IF A. 1 62/1 6 THEN m ELSE I - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE I - - the requirement to be able to Insert Itself In the subsequent transactions In a 

dialog. 

c8: IF A.162/8A THEN m ELSE I - - authentication between UA and proxy. 

c9: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted Identity. 

clO: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted Identity 
within trusted networks. 

c1 1 : IF A.162/30A or A.162/30B THEN m ELSE I - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c12: IF A.162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c13: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN 1 ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "Id" or passing on of the Privacy header transparently. 
c14: IF A.162/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c15: IF A.162/37 THEN 1 ELSE n/a - - the P-Called-Party-ID header extension. 

c16: IF A.162/37 AND A.3/2 THEN m ELSE IF A.162/37 AND A.3/3 THEN I ELSE n/a - - the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c1 7: IF A.I 62/38 THEN m ELSE n/a - - the P-Vlslted-Network-ID header extension. 

c1 8: IF A.I 62/39 THEN m ELSE I - - reading, or deleting the P-Vlslted-Network-ID header before proxying the 
request or response. 

c19: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c20: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN I ELSE n/a - - adding, deleting, reading or modifying the P- 
Charglng-Vector header before proxying the request or response or the P-Charglng-Vector header 
extension. 

c21 : IF A.I 62/44 THEN m ELSE n/a - - the P-Charglng-Functlon-Addresses header extension. 

c22: IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charglng- 

Functlon-Addresses header before proxying the request or response, or the P-Charging-Functlon- 

Addresses header extension. 

c23: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c24: IF A.162/43 THEN m ELSE IF A.162/41 THEN I ELSE n/a - - act as subsequent entity within trust network 
for access network Information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c25: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/12 - - OPTIONS request 



Table A.234: Supported message bodies within tlie OPTIONS request 



Item 


■Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/13 - - OPTIONS response 
Prerequisite: A.164/1 - - 100 (Trying) 



Table A.235: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


c1 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 
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Prerequisite A. 163/13 - - OPTIONS response 



Table A.236: Supported headers within the OPTIONS response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


uail-lnto 


[26J 20.9 


m 


m 


[26] 20.9 


c3 


c3 


2 


Content- Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


1 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


1 1 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


1 1 A 


P-Access-Networl<-lnfo 


[52] 4.4 


c13 


c13 


[52] 4.4 


c14 


c14 


1 1 B 


P-Asserted-ldentity 


[34] 9.1 


c5 


c5 


[34] 9.1 


c6 


c6 


11C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c1 1 


c1 1 


[52] 4.5 


c12 


c12 


11D 


P-Chiarging-Vector 


[52] 4.6 


c9 


c9 


[52] 4.6 


c10 


clO 


11E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c4 


n/a 


11F 


Privacy 


[33] 4.2 


c7 


c7 


[33] 4.2 


c8 


c8 


11G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c15 


c15 


11H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 



c3: IF A.I 62/1 9C OR A.I 62/1 9D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c4: IF A.I 62/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c5: IF A.162/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c6: IF A.162/30Aor A.I 62/308 THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c7: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c8: IF A.162/31D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c9: IF A. 162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

clO: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

cl 1 : IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c12: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Gharging-Function- 

Addresses header extension. 

CIS: IF A.1 62/43 THEN x ELSE IF A.1 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c14: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c15: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 
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Prerequisite A. 163/13 - - OPTIONS response 
Prerequisite: A. 164/6 - - 2xx 



Table A.237: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


1 


1 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


1 


3 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


1 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


9 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


12 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


1 


1 


c3: 


IF A.1 62/1 5 THEN o ELSE i - - the requirement to be able to use separate URIs In the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/1 3 - - OPTIONS response 

Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/1 1 OR A.164/12 OR A.164/35 - - 3xx or 485 (Ambiguous) 
Table A.238: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
Status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


1 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


1 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


1 


c1: 


IF A.I 62/1 9E THEN m ELSE 1 - 


- deleting Contact headers. 









Prerequisite A. 163/13 - - OPTIONS response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 

Table A.239: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


1 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


1 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A. 164/17 OR A. 164/23 OR A. 164/30 OR A. 164/36 OR A. 164/42 OR A. 164/45 OR A. 164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 

Table A.240: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






5 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/13 - - OPTIONS response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.241 : Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/1 3 - - OPTIONS response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 

Table A.242: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/13 - - OPTIONS response 
Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 

Table A.243: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[261 20.2 


m 


m 


[261 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






4 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






5 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/13 - - OPTIONS response 
Prerequisite: A.164/27 - - 420 (Bad Extension) 

Table A.244: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: 


IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/13 - - OPTIONS response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.244A: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A. 163/1 3 - - OPTIONS response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.245: Supported headers within the OPTIONS response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/13 - - OPTIONS response 



Table A.246: Supported message bodies within the OPTIONS response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.10 PRACK method 

Prerequisite A. 163/14 - - PRACK request 



Table A.247: Supported headers within the PRACK request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


c3 


8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c3 


9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c3 


10 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


15 


IVIax-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


16 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


16A 


P-Access-Network-lnfo 


[52] 4.4 


c14 


c14 


[52] 4.4 


c15 


c15 


16B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c12 


c12 


[52] 4.5 


c13 


c13 


16C 


P-Charging-Vector 


[52] 4.6 


clO 


n/a 


[52] 4.6 


c11 


n/a 


16D 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c9 


c9 


17 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


18 


Proxy-Require 


[28] 20.29 


m 


m 


[26] 20.29 


m 


m 


19 


RAck 


[27] 7.2 


m 


m 


[27] 7.2 


i 


i 


20 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


21 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


22 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


23 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


24 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


25 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


26 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


27 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE I - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

c8; IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c9: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
clO: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c1 1 : IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c12: IF A.162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c13: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c14: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c15: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/14 - - PRACK request 



Table A.248: Supported message bodies within the PRACK request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A. 163/1 5 - - PRACK response 
Prerequisite: A.164/1 - - 100 (Trying) 



Table A.249: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 
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Prerequisite A. 163/1 5 - - PRACK response 



Table A.250: Supported headers within the PRACK response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 


i 


c2 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c2 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c2 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c2 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c1 


c1 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c2 


10A 


P-Access-Networl<-lnfo 


[52] 4.4 


c9 


c9 


[52] 4.4 


c10 


clO 


1 0B 


P-CPnarging-Function- 
Addresses 


[52] 4.5 


c7 


c7 


[52] 4.5 


c8 


c8 


10C 


P-Cliarging-Vector 


[52] 4.6 


c5 


n/a 


[52] 4.6 


c6 


n/a 


10D 


Privacy 


[33] 4.2 


c3 


c3 


[33] 4.2 


c4 


c4 


10E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c11 


c11 


10F 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



c1 : IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c3: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 



c4: IF A.162/31D OR A.162/31G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c5: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c6: IF A.1 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Gharging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c7: IF A. 162/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c8: IF A.162/44ATHEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c9: IF A.1 62/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access networl< information that can route outside the trust networl<, the P-Access-Networl<-lnfo header 

extension. 

c10: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust networl< 
for access networl< information that can route outside the trust networl<, the P-Access-Networl<-lnfo header 
extension. 

c1 1 : IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 



Prerequisite A. 163/1 5 - - PRACK response 
Prerequisite: A. 164/6 - - 2xx 



Table A.251 : Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


OB 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


1 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 
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c3: IF A.1 62/1 5 THEN o ELSE i - - the requirement to be able to use separate URIs In the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/1 5 - - PRACK response 

Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/11 OR A.164/12 OR A.164/35 - - 3xx or 485 (Ambiguous) 



Table A.252: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


1 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


Cl 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


1 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


1 


c1: 


IF A.1 62/1 9E THEN m ELSE 1 - 


- deleting Contact headers. 









Prerequisite A. 163/15 - - PRACK response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 



Table A.253: Supported headers within the PRACK response 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


1 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


1 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


1 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/1 5 - - PRACK response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 



Tabie A.254: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

status 


Profile 
status 


Ref. 


RFC 

status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/1 5 - - PRACK response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.255: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







ETSI 



3GPP TS 24.229 version 5.11 .1 Reiease 5 21 1 ETSi TS 1 24 229 V5.1 1 .1 (2005-01 ) 

Prerequisite A. 163/1 5 - - PRACK response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 



Table A.256: Supported headers within the PRACK response 



Item 


hHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


1 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


1 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


1 



Prerequisite A. 163/1 5 - - PRACK response 
Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 

Table A.257: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/15 - - PRACK response 
Prerequisite: A. 164/27 - - 420 (Bad Extension) 

Table A.258: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/1 5 - - PRACK response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.258A: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


Cl 


cl 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.I 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 
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Prerequisite A. 163/1 5 - - PRACK response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 



Table A.259: Supported headers within the PRACK response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/1 5 - - PRACK response 



Table A.260: Supported message bodies within the PRACK response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.11 REFER method 

Prerequisite A. 163/16 - - REFER request 



Table A.261 : Supported headers within the REFER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


OB 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


1 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






1 A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


Cl 


3 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


4 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






5A 


Content-Disposition 


[26] 20.1 1 


m 


m 


[26] 20.1 1 






5B 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


-1 


-! 


5C 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






6 


Content-Lengtli 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


7 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


8 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


9 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


10 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


11 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


12 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


13 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


14 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


14A 


P-Access-Networl<-lnfo 


[52] 4.4 


c22 


c22 


[52] 4.4 


c23 


c23 


148 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[34] 9.1 


c10 


clO 


14C 


P-Called-Party-ID 


[52] 4.2 


c13 


c13 


[52] 4.2 


c14 


c15 


14D 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c20 


[52] 4.5 


c21 


c21 


14E 


P-Charging-Vector 


[52] 4.6 


c18 


c18 


[52] 4.6 


c19 


c19 


14F 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c8 


c8 


14G 


P-Visited-Network-ID 


[52] 4.3 


c16 


n/a 


[52] 4.3 


c17 


n/a 


14H 


Privacy 


[33] 4.2 


c11 


c11 


[33] 4.2 


c12 


c12 


15 


Proxy-Autliorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


16 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


17 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


18 


Refer-To 


[36] 3 


c3 


c3 


[36] 3 


c4 


c4 


19 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


20 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


20A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


208 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


20C 


Subject 


[26] 20.36 


m 


m 


[26] 20.36 






21 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


22 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 






23 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


24 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 






25 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 

c8; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c9: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c10: IF A.162/30Aor A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 1 : IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c12: IF A.1 62/31 D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.1 62/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c14: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 AND A.3/2 THEN m ELSE IF A.1 62/37 AND A.3/3 THEN i ELSE n/a -- the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c1 6: IF A.1 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 7: IF A.1 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 
request or response. 

c18: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c19: IF A. 162/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a -- adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c20: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c21 : IF A.1 62/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c22: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c23: IF A.1 62/43 THEN m ELSE IF A.1 62/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c24: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/16 - - REFER request 



Table A.262: Supported message bodies within the REFER request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/17 - - REFER response 
Prerequisite: A.164/1 - - 100 (Trying) 



Table A.263: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


c1 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


c1: 


IF A.I 62/9 THEN m ELSE i - - insertion of date in requests and responses. 
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Prerequisite A. 163/17 - - REFER response 



Table A.264: Supported headers within the REFER response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


Content- Disposition 


[26J 20.1 1 


m 


m 


[26] 20.1 1 


i 


i 


2 


Content- Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


1 


3 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


4 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


5 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


6 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


7 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


8 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


9 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


10A 


P-Access-N etwo rk- 1 nf o 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


10B 


P-Asserted-ldentity 


[34] 9.1 


c4 


c4 


[34] 9.1 


c5 


c5 


10C 


P-Cliarging-Function- 
Addresses 


[52] 4.5 


clO 


clO 


[52] 4.5 


cl 1 


cl 1 


10D 


P-Cliarging-Vector 


[52] 4.6 


c8 


c8 


[52] 4.6 


c9 


c9 


10E 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10F 


Privacy 


[33] 4.2 


c6 


c6 


[33] 4.2 


c7 


c7 


10G 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


10H 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A. 162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.I 62/1 9A OR A.I 62/1 9B THEN m ELSE i - - reading, adding or concatenating tine Organization tieader. 

c3: IF A.I 62/30A THEN m ELSE n/a - - act as first entity wittiin the trust domain for asserted identity. 
c4: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 



c5: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c6: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

cl 0: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension, 
cl 1 : IF A.I 62/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 
Function-Addresses header before proxying the request or response, or the P-Gharging-Function- 

Addresses header extension. 

c12: IF A. 162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.I 62/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c14: IF A.162/11 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 
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Prerequisite A. 163/17 - - REFER response 
Prerequisite: A. 164/7 - - 202 (Accepted) 



Table A.265: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


1 


i 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


1 


i 


5 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: 


IF A.1 62/1 5 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/8 OR A. 164/9 OR A. 164/10 OR A. 164/1 1 OR A. 164/12 OR A. 164/35 - - 3xx or 485 (Ambiguous) 



Table A.266: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


i 


2 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


1 


i 


c1: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/17 - - REFER response 

Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/11 OR A.164/12 - - 401 (Unauthorized) 



Table A.267: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


i 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 



Table A.268: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






6 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/17 - - REFER response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.269: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 



Table A.270: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


4 


Proxy-Authenticate 


[26] 20.27 







[26] 20.27 







7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/17 - - REFER response 

Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 



Table A.271 : Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[261 20.2 


m 


m 


[261 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/17 - - REFER response 
Prerequisite: A. 164/27 - - 420 (Bad Extension) 



Table A.272: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: 


IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/17 - - REFER response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.272A: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A. 163/1 7 - - REFER response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.273: Supported headers within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/17 - - REFER response 



Table A.274: Supported message bodies within the REFER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.12 REGISTER method 

Prerequisite A. 163/1 8 - - REGISTER request 



Table A.275: Supported headers within the REGISTER request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7, 
[49] 


m 


m 


[26] 20.7, 
[49] 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


7 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c2 


c2 


8 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


9 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


10 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


11 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


12 


Content-Lengtli 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


13 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


14 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


15 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


m 


m 


16 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


18 


IVlax- Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


19 


IVIIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


20 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


20A 


P-Access-Network-lnfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


20B 


P-Cliarging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


20C 


P-Cliarging-Vector 


[52] 4.6 


c12 


c12 


[52] 4.6 


c13 


c13 


20D 


P-Visited-Networl<-ID 


[52] 4.3 


clO 


clO 


[52] 4.3 


c1 1 


c11 


20E 


Patli 


[35] 4.2 


c6 


c6 


[35] 4.2 


c6 


c6 


20F 


Privacy 


[33] 4.2 


c8 


c8 


[33] 4.2 


c9 


c9 


21 


Proxy-Authiorization 


[26] 20.28 


m 


m 


[26] 20.28 


c7 


c7 


22 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


23 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c4 


c4 


24 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


24A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


24B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


25 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c5 


c5 


26 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


27 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


28 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


29 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.162/1 1 OR A.1 62/1 2 THEN m ELSE 1 - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 

request or response for methods other than REGISTER. 
c5: IF A.1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c6: IF A.162/29 THEN m ELSE n/a - - PATH header support. 

c7: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c8: IF A. 162/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c9: IF A.162/31D OR A.162/31G THEN m ELSE IF A.1 62/31 C THEN 1 ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c1 0: IF A.1 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 1 : IF A.1 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 

request or response. 

c12: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A.1 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c14: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c15: IF A.162/44A THEN m ELSE IF A.162/44 THEN 1 ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c16: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust networl< 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c17: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c18: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/1 8 - - REGISTER request 



Table A.276: Supported message bodies within the REGISTER request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A.164/1 - - 100 (Trying) 



Table A.277: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


2 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


3 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


4 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


m 


m 


5 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


6 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


7 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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Prerequisite A. 163/19 - - REGISTER response 



Table A.278: Supported headers within the REGISTER response - all remaining status-codes 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


uail-lnto 


[26J 20.9 


m 


m 


[26] 20.9 


c2 


c2 


2 


Content- Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


i 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


m 


m 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


1 1 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c1 


c1 


1 1 A 


P-Access-Networl<-lnfo 


[52] 4.4 


c9 


c9 


[52] 4.4 


clO 


clO 


1 1 B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c7 


c7 


[52] 4.5 


c8 


c8 


11C 


P-Charging-Vector 


[52] 4.6 


c5 


c5 


[52] 4.6 


c6 


c6 


11D 


Privacy 


[33] 4.2 


c3 


c3 


[33] 4.2 


c4 


c4 


11E 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c11 


c11 


11F 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


12 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


13 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


13A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


14 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


15 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



c1: IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c2: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c3: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c4: IF A.1 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c5: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c6: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c7: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c8: IF A.1 62/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c9: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 

for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c1 0: IF A.1 62/43 THEN m ELSE IF A.1 62/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c1 1 : IF A.1 62/1 1 OR A.1 62/1 2 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 
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Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A. 164/6 - - 2xx 

Table A.279: Supported headers within the REGISTER response 



ItGin 


ncauci 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






1A 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






1B 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 






5 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






5A 


P-Associated-URI 


[52] 4.1 


c8 


c8 


[52] 4.1 


c9 


clO 


6 


Path 


[35] 4.2 


c3 


c3 


[35] 4.2 


c4 


c4 


8 


Service-Route 


[38] 5 


c5 


c5 


[38] 5 


c6 


c7 


9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


1 


i 



c2: IF A.3/2 OR A.3/3A THEN m ELSE n/a - - P-CSGF or l-GSGF (THIG). 

c3: IF A.I 62/29 THEN m ELSE n/a - - Path extension support. 

c4: IF A.I 62/29 THEN i ELSE n/a - - Path extension support. 

c5: IF A.I 62/32 THEN m ELSE n/a - - Service-Route extension support. 

c6: IF A.I 62/32 THEN i ELSE n/a - - Service-Route extension support. 

c7: IF A.162/32 THEN (IF A.3/2 THEN m ELSE i) ELSE n/a - - Service-Route extension and P-GSGF. 

c8: IF A.I 62/36 THEN m ELSE n/a - - the P-Associated-URI extension. 

c9: IF A.I 62/36 THEN i ELSE n/a - - the P-Associated-URI extension. 

clO: IF A.I 62/36 AND A.3/2 THEN m ELSE IF A.I 62/36 AND A.3/3 THEN i ELSE n/a - - the P-Associated-URI 
extension and P-GSGF or l-GSGF. 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A.164/8 OR A.164/9 OR A.164/10 OR A.164/11 OR A.164/12 OR A.164/35 - - 3xx or 485 (Ambiguous) 
Table A.280: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


c2 


c2 


4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c2: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 



Table A.281 : Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


6 


Security-Server 


[48] 2 


X 


Cl 


[48] 2 


n/a 


n/a 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 




i 


10 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 




i 


c1: 


IF A.I 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 



ETSI 



3GPP TS 24.229 version 5.11 .1 Release 5 224 ETSI TS 1 24 229 V5.1 1 .1 (2005-01 ) 



Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 



Table A.282: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






6 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 

Table A.283: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


2 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/19 - - REGISTER response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 

Table A.284: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


5 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


9 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 

Table A.285: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






4 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






5 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






9 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A.164/27 - - 420 (Bad Extension) 



Table A.286: Supported headers within the REGISTER response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






8 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: 


IF A.1 62/1 7 THEN m ELSE.i 















Prerequisite A. 163/1 9 - - REGISTER response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 
Table A.286A: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


Cl 


cl 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.I 62/47 THEN m ELSE n/a 


- - security mechanism agreement for the session initiation protocol. 



Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A. 164/29 - - 423 (Interval Too Brief) 

Table A.287: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


3 


Error-Info 


[26] 20.18 







[26] 20.18 







5 


Min-Expires 


[26] 20.23 


m 


m 


[26] 20.23 


1 


i 


8 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 



Prerequisite A. 163/19 - - REGISTER response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.288: Supported headers within the REGISTER response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/19 - - REGISTER response 



Table A.289: Supported message bodies within the REGISTER response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.13 SUBSCRIBE method 

Prerequisite A. 163/20 - - SUBSCRIBE request 



Table A.290: Supported headers within the SUBSCRIBE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






3A 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






4 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


5 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


6 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


6A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






7 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.1 1 






8 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


i 


9 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 






10 


Content-Length 


[26] 20.14 


nn 


m 


[26] 20.14 


m 


m 


11 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


12 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


13 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


14 


Event 


[28] 7.2.1 


m 


m 


[28] 7.2.1 


m 


m 


15 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


i 


i 


16 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


17 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


18 


MIME-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


18A 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


18B 


P-Access-Networl<-lnfo 


[52] 4.4 


c22 


c22 


[52] 4.4 


c23 


c23 


18C 


P-Asserted-ldentity 


[34] 9.1 


c9 


c9 


[34] 9.1 


clO 


clO 


18D 


P-Called-Party-ID 


[52] 4.2 


c13 


c13 


[52] 4.2 


c14 


c15 


18E 


P-Charging-Function- 
Addresses 


[52] 4.5 


c20 


c20 


[52] 4.5 


c21 


c21 


18F 


P-Charging-Vector 


[52] 4.6 


c18 


c18 


[52] 4.6 


c19 


c19 


18G 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c8 


c8 


18H 


P-Visited-Networl<-ID 


[52] 4.3 


c16 


n/a 


[52] 4.3 


c17 


n/a 


181 


Privacy 


[33] 4.2 


c11 


c11 


[33] 4.2 


c12 


c12 


19 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c4 


c4 


20 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


21 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


22 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


23 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


23A 


Security-Client 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


23B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c24 


c24 


24 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


25 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


26 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


27 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


28 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE 1 - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE 1 - - reading, adding or concatenating the Organization header. 

c4: IF A.162/8A THEN m ELSE i - - authentication between UA and proxy. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN m ELSE i - - the requirement to be able to insert itself in the subsequent transactions in 

a dialog. 

c8; IF A.162/30A THEN m ELSE n/a - - act as first entity within the trust domain for asserted identity. 

c9: IF A.1 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 

within trusted networks. 

c10: IF A.162/30Aor A.162/30B THEN m ELSE i - - extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c1 1 : IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c12: IF A.1 62/31 D OR A.1 62/31 G THEN m ELSE IF A.1 62/31 C THEN i ELSE n/a - - application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c13: IF A.1 62/37 THEN m ELSE n/a - - the P-Called-Party-ID header extension. 
c14: IF A.162/37 THEN i ELSE n/a - - the P-Called-Party-ID header extension. 

c15: IF A.162/37 AND A.3/2 THEN m ELSE IF A.1 62/37 AND A.3/3 THEN i ELSE n/a -- the P-Called-Party-ID 

header extension and P-CSCF or l-CSCF. 
c1 6: IF A.1 62/38 THEN m ELSE n/a - - the P-Visited-Network-ID header extension. 

c1 7: IF A.1 62/39 THEN m ELSE i - - reading, or deleting the P-Visited-Network-ID header before proxying the 
request or response. 

c18: IF A.1 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c19: IF A. 162/46 THEN m ELSE IF A.1 62/45 THEN i ELSE n/a -- adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c20: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c21 : IF A.1 62/44A THEN m ELSE IF A.1 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c22: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c23: IF A.1 62/43 THEN m ELSE IF A.1 62/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c24: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/20 - - SUBSCRIBE request 



Table A.291 : Supported message bodies witliin the SUBSCRIBE request 



Item 


IHeader 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/21 - - SUBSCRIBE response 



Table A.292: Supported headers within the SUBSCRIBE response - all status-codes 



item 


Header 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oali-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


d. 


Content- Disposition 


[26J 20.1 1 


m 


m 


[26J 20.1 1 


i 


i 


3 


Content- Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


1 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


i 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


i 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


IVIIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


i 


10A 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


10B 


P-Access-N etwo rk- 1 nf o 


[52] 4.4 


c12 


c12 


[52] 4.4 


c13 


c13 


IOC 


P-Asserted-ldentity 


[34] 9.1 


c4 


c4 


[34] 9.1 


c5 


c5 


10D 


P-Cliarging-Function- 
Addresses 


[52] 4.5 


clO 


clO 


[52] 4.5 


cl 1 


cl 1 


10E 


P-Cliarging-Vector 


[52] 4.6 


c8 


c8 


[52] 4.6 


c9 


c9 


10F 


P-Preferred-ldentity 


[34] 9.2 


X 


X 


[34] 9.2 


c3 


n/a 


10G 


Privacy 


[33] 4.2 


c6 


c6 


[33] 4.2 


c7 


c7 


10H 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c14 


c14 


101 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A. 162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2: IF A.I 62/1 9A OR A.I 62/1 98 THEN m ELSE i - - reading, adding or concatenating tine Organization tieader. 

c3: IF A.I 62/30A THEN m ELSE n/a - - act as first entity wittiin the trust domain for asserted identity. 
c4: IF A.I 62/30 THEN m ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity 
within trusted networks. 



c5: IF A.162/30AorA.162/30BTHEN m ELSE i -- extensions to the Session Initiation Protocol (SIP) for 

asserted identity within trusted networks or subsequent entity within trust network that can route outside the 
trust network. 

c6: IF A.I 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 

c7: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 C THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c8: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c9: IF A.162/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

cl 0: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension, 
cl 1 : IF A.I 62/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 
Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c12: IF A. 162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.I 62/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c14: IF A.162/11 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 



Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A. 164/6 AND A. 164/7 - - 2xx 

Table A.293: Supported headers within the SUBSCRIBE response 
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item 


IHeader 


Sending 


Receiving 


Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


i 


1 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 


i 


i 


1A 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


1 


i 


2 


Expires 


[26] 20.19 


m 


m 


[26] 20.19 


1 


i 


3 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c3 


c3 


6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c3: IF A.1 62/1 5 THEN m ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/8 OR A. 164/9 OR A. 164/10 OR A. 164/1 1 OR A. 164/12 OR A. 164/35 - - 3xx or 485 (Ambiguous) 
Table A.294: Supported headers within the SUBSCRIBE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


i 


1 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1: 


IF A.1 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A.163/21 - - SUBSCRIBE response 
Prerequisite: A.I64/I4 - - 401 (Unauthorized) 

Table A.295: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


i 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A.163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/50 OR A.164/51 - - 404, 413, 

480, 486, 500, 600, 603 

Table A.296: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.297: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 



Table A.298: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


2 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 

Table A.299: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[261 20.2 


m 


m 


[261 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






4 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






5 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A. 164/27 - - 420 (Bad Extension) 

Table A.300: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






5 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/21 - - SUBSCRIBE response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.300A: Supported headers within the SUBSCRIBE response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A. 164/29 - - 423 (Interval Too Brief) 

Table A.301 : Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






2 


IVIin-Expires 


[26] 20.23 


m 


m 


[26] 20.23 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A. 164/34 - - 484 (Address Incomplete) 

Table A.302: Supported headers within the SUBSCRIBE response 



Item 


{Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[261 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A.164/39 - - 489 (Bad Event) 

Table A.303: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


1 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


Cl 


cl 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


c1: 


IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 








NOTE; 


c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 
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Prerequisite A. 163/21 - - SUBSCRIBE response 
Prerequisite: A.164/45 - - 503 (Service Unavailable) 



Table A.303A: Supported headers within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






1 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






3 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/21 - - SUBSCRIBE response 

Table A.304: Supported message bodies within the SUBSCRIBE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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A.2.2.4.14 UPDATE method 

Prerequisite A. 163/22 - - UPDATE request 



Table A.305: Supported headers within the UPDATE request 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 


2 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 


i 


i 


3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 


i 


i 


4 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


5 


Allow-Events 


[28] 7.2.2 


m 


m 


[28] 7.2.2 


c1 


Cl 


6 


Authorization 


[26] 20.7 


m 


m 


[26] 20.7 


i 


i 


7 


Call-ID 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


8 


Call-Info 


[26] 20.9 


m 


m 


[26] 20.9 


c8 


c8 


9 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


i 


i 


10 


Content-Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


c4 


c4 


11 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


c4 


c4 


12 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


c4 


c4 


13 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


14 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


c4 


c4 


15 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


16 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


c2 


c2 


17 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


18 


Max-Forwards 


[26] 20.22 


m 


m 


[26] 20.22 


m 


m 


19 


IVIII^E-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c4 


20 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c3 


c3 


20A 


P-Access-Networl<-lnfo 


[52] 4.4 


c16 


c16 


[52] 4.4 


c17 


c17 


20B 


P-Charging-Function- 
Addresses 


[52] 4.5 


c14 


c14 


[52] 4.5 


c15 


c15 


20C 


P-Charging-Vector 


[52] 4.6 


c12 


c12 


[52] 4.6 


c13 


c13 


20D 


Privacy 


[33] 4.2 


clO 


clO 


[33] 4.2 


c11 


c11 


21 


Proxy-Authorization 


[26] 20.28 


m 


m 


[26] 20.28 


c9 


c9 


22 


Proxy-Require 


[26] 20.29 


m 


m 


[26] 20.29 


m 


m 


23 


Record-Route 


[26] 20.30 


m 


m 


[26] 20.30 


c7 


c7 


24 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c5 


c5 


25A 


Security-Client 


[48] 2.3.1 


x 


X 


[48] 2.3.1 


c18 


c18 


25B 


Security-Verify 


[48] 2.3.1 


X 


X 


[48] 2.3.1 


c18 


c18 


25 


Route 


[26] 20.34 


m 


m 


[26] 20.34 


m 


m 


26 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


c6 


c6 


27 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


28 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


29 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


30 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 
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c1 : IF A. 4/20 THEN m ELSE i - - SIP specific event notification extension. 

c2: IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c3; IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating the Organization header. 

c4: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c5: IF A.162/1 1 OR A.162/13 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 

c6: IF A. 1 62/1 6 THEN m ELSE i - - reading the contents of the Supported header before proxying the 

response. 

c7: IF A.162/14 THEN o ELSE i - - the requirement to be able to insert itself in the subsequent transactions in a 

dialog. 

c8; IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 

c9: IF A.1 62/8A THEN m ELSE i - - authentication between UA and proxy. 

c10: IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c11: IF A.162/31D OR A.1 62/31 G THEN m ELSE IF A.1 62/310 THEN i ELSE n/a -- application of the privacy 
option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c12: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c13: IF A.1 62/46 THEN m ELSE IF A.162/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 
Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c14: IF A.1 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

c15: IF A.162/44A THEN m ELSE IF A.162/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c16: IF A.162/43 THEN x ELSE IF A.162/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c17: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 

extension. 

c18: IF A. 4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. 

NOTE: c1 refers to the UA role major capability as this is the case of a proxy that also acts as a UA specifically for 
SUBSCRIBE and NOTIFY. 



Prerequisite A. 163/22 - - UPDATE request 



Table A.306: Supported message bodies within tlie UPDATE request 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 
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Prerequisite A. 163/22 - - UPDATE response 



Table A.307: Supported headers within the UPDATE response - all remaining status-codes 



Item 


iHeader 


Sending 


Receiving 


Ret. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Oaii-iu 


[26] 20.8 


m 


m 


[26] 20.8 


m 


m 


1 A 


uail-lnto 


[26J 20.9 


m 


m 


[26] 20.9 


c4 


c4 


2 


Content- Disposition 


[26] 20.11 


m 


m 


[26] 20.11 


i 


c3 


3 


Content-Encoding 


[26] 20.12 


m 


m 


[26] 20.12 


i 


c3 


4 


Content-Language 


[26] 20.13 


m 


m 


[26] 20.13 


i 


c3 


5 


Content-Length 


[26] 20.14 


m 


m 


[26] 20.14 


m 


m 


6 


Content-Type 


[26] 20.15 


m 


m 


[26] 20.15 


i 


c3 


7 


Cseq 


[26] 20.16 


m 


m 


[26] 20.16 


m 


m 


8 


Date 


[26] 20.17 


m 


m 


[26] 20.17 


Cl 


cl 


9 


From 


[26] 20.20 


m 


m 


[26] 20.20 


m 


m 


10 


MIIVIE-Version 


[26] 20.24 


m 


m 


[26] 20.24 


i 


c3 


10A 


Organization 


[26] 20.25 


m 


m 


[26] 20.25 


c2 


c2 


10B 


P-Access-Networl<-lnfo 


[52] 4.4 


c1 1 


c1 1 


[52] 4.4 


c12 


c12 


10C 


P-Charging-Function- 
Addresses 


[52] 4.5 


c9 


c9 


[52] 4.5 


clO 


clO 


10D 


P-Charging-Vector 


[52] 4.6 


c7 


n/a 


[52] 4.6 


c8 


n/a 


10E 


Privacy 


[33] 4.2 


c5 


c5 


[33] 4.2 


c6 


c6 


10F 


Require 


[26] 20.32 


m 


m 


[26] 20.32 


c13 


c13 


10G 


Server 


[26] 20.35 


m 


m 


[26] 20.35 


i 


i 


11 


Timestamp 


[26] 20.38 


m 


m 


[26] 20.38 


i 


i 


12 


To 


[26] 20.39 


m 


m 


[26] 20.39 


m 


m 


12A 


User-Agent 


[26] 20.41 


m 


m 


[26] 20.41 


i 


i 


13 


Via 


[26] 20.42 


m 


m 


[26] 20.42 


m 


m 


14 


Warning 


[26] 20.43 


m 


m 


[26] 20.43 


i 


i 



cl : IF A.162/9 THEN m ELSE i - - insertion of date in requests and responses. 

c2; IF A.162/19A OR A.162/19B THEN m ELSE i - - reading, adding or concatenating tlie Organization lieader. 

c3: IF A.3/2 OR A.3/4 THEN m ELSE i - - P-CSCF or S-CSCF. 

c4: IF A.162/19C OR A.162/19D THEN m ELSE i - - reading, adding or concatenating the Call-Info header. 
c5: IF A.1 62/31 THEN m ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP). 
c6: IF A.I 62/31 D OR A.I 62/31 G THEN m ELSE IF A.I 62/31 THEN i ELSE n/a - - application of the privacy 

option "header" or application of the privacy option "id" or passing on of the Privacy header transparently. 
c7: IF A.I 62/45 THEN m ELSE n/a - - the P-Charging-Vector header extension. 

c8: IF A.I 62/46 THEN m ELSE IF A.I 62/45 THEN i ELSE n/a - - adding, deleting, reading or modifying the P- 

Charging-Vector header before proxying the request or response or the P-Charging-Vector header 
extension. 

c9: IF A.I 62/44 THEN m ELSE n/a - - the P-Charging-Function-Addresses header extension. 

ClO: IF A.162/44A THEN m ELSE IF A.I 62/44 THEN i ELSE n/a - - adding, deleting or reading the P-Charging- 

Function-Addresses header before proxying the request or response, or the P-Charging-Function- 

Addresses header extension. 

c11: IF A.I 62/43 THEN x ELSE IF A.I 62/41 THEN m ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c12: IF A.162/43 THEN m ELSE IF A.162/41 THEN i ELSE n/a - - act as subsequent entity within trust network 
for access network information that can route outside the trust network, the P-Access-Network-lnfo header 
extension. 

c13: IF A.I 62/11 OR A.I 62/1 3 THEN m ELSE i - - reading the contents of the Require header before proxying 

the request or response or adding or modifying the contents of the Require header before proxying the 
request or response for methods other than REGISTER. 



Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A. 164/6 - - 2xx 



Table A.308: Supported headers within the UPDATE response 



Item 


IHeader 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


OA 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 


i 


i 
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OB 


Accept-Encoding 


[26] 20.2 


m 


m 


[26] 20.2 






OC 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Authentication-Info 


[26] 20.6 


m 


m 


[26] 20.6 






3 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 






6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






c3: IF A.162/15 THEN o ELSE i - - the requirement to be able to use separate URIs in the upstream direction 
and downstream direction when record routeing. 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/8 OR A. 164/9 OR A. 164/10 OR A. 164/11 OR A. 164/12 - - 3xx 

Table A.309: Supported headers within the UPDATE response 



item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


i 


2 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1: 


IF A.I 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A.164/14 - - 401 (Unauthorized) 

Tabie A.309A: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


1 


i 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


3 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


5 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


1 


i 


6 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/17 OR A.164/23 OR A.164/30 OR A.164/36 OR A.164/42 OR A.164/45 OR A.164/50 OR 
A.164/51 - - 404, 413, 480, 486, 500, 503, 600, 603 

Table A.310: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






5 


Retry-After 


[26] 20.33 


m 


m 


[26] 20.33 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 
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Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A.164/18 - - 405 (Method Not Allowed) 



Table A.31 1 : Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A. 164/20 - - 407 (Proxy Authentication Required) 

Table A.31 2: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 

Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


1 


i 


4 


Proxy-Authenticate 


[26] 20.27 


m 


m 


[26] 20.27 


m 


m 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


8 


www-Authenticate 


[26] 20.44 


m 


m 


[26] 20.44 


i 


i 



Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A. 164/25 - - 415 (Unsupported Media Type) 

Table A.31 3: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Accept 


[26] 20.1 


m 


m 


[26] 20.1 






2 


Accept-Encoding 


[261 20.2 


m 


m 


[261 20.2 






3 


Accept-Language 


[26] 20.3 


m 


m 


[26] 20.3 






4 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






6 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






10 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 







Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A.164/27 - - 420 (Bad Extension) 

Table A.31 4: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 






2 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 






6 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 






7 


Unsupported 


[26] 20.40 


m 


m 


[26] 20.40 


c3 


c3 


c3: 


IF A.I 62/1 8 THEN m ELSE i - - reading the contents of the Unsupported header before proxying the 420 
response to a method other than REGISTER. 
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Prerequisite A. 163/23 - - UPDATE response 

Prerequisite: A.164/28 OR A.164/41A - - 421 (Extension Required), 494 (Security Agreement Required) 



Table A.314A: Supported headers within the UPDATE response 



Item 


hHeader 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 








[26] 20.5 


m 


m 


2 


Error-Info 


[26] 20.18 








[26] 20.18 








3 


Security-Server 


[48] 2 


c1 


c1 


[48] 2 


n/a 


n/a 


4 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


m 


m 


c1: 


IF A.1 62/47 THEN m ELSE n/a 


- - security meclianism agreement for the session initiation protocol. 



Prerequisite A. 163/23 - - UPDATE response 
Prerequisite: A. 164/35 - - 485 (Ambiguous) 

Table A.315: Supported headers within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Allow 


[26] 20.5 


m 


m 


[26] 20.5 


i 


i 


2 


Contact 


[26] 20.10 


m 


m 


[26] 20.10 


Cl 


cl 


3 


Error-Info 


[26] 20.18 


m 


m 


[26] 20.18 


i 


i 


7 


Supported 


[26] 20.37 


m 


m 


[26] 20.37 


i 


i 


c1: 


IF A.1 62/1 9E THEN m ELSE i - 


- deleting Contact headers. 









Prerequisite A. 163/23 - - UPDATE response 

Table A.316: Supported message bodies within the UPDATE response 



Item 


Header 


Sending 


Receiving 






Ref. 


RFC 
status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 

















A.3 Profile definition for the Session Description Protocol 
as used in the present document 

A.3.1 Introduction 

Void. 

A.3. 2 User agent role 

This subclause contains the ICS proforma tables related to the user role. They need to be completed only for UA 

implementations. 

Prerequisite: A.2/1 — user agent role 
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A.3.2.1 Major capabilities 



Table A.317: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC Status 


Profile status 




Capabilities within main protocol 




















Extensions 








22 


Integration of resource management 
and SIP? 


[30] 





m 


23 


Grouping of media lines 


[531 





c1 


24 


Mapping of Media Streams to Resource 
Reservation Flows 


[54] 





c1 


25 


SDP Bandwidtli Modifiers for RTCP 
Bandwidth 


[56] 





o(NOTE 1) 


c1: IFA.3/1 THEN m ELSE n/a--UE role. 








NOTE 1: For "video" and "audio" media types that utilise RTP/RTCP, it shall be specified. For other media types, it 


may be specified. 









A.3.2.2 SDP types 

Table A.318: SDP types 



Item 


Type 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 




Session level description 


1 


v= (protocol version) 


[39] 6 


m 


m 


[39] 6 


m 


m 


2 


0= (owner/creator and session 
identifier) 


[39] 6 


m 


m 


[39] 6 


m 


m 


3 


8= (session name) 


[39] 6 


m 


m 


[39] 6 


m 


m 


4 


i= (session information) 


[39] 6 







[39] 6 






5 


u= (URI of description) 


[39] 6 





n/a 


[39] 6 




n/a 


6 


e= (email address) 


[39] 6 





n/a 


[39] 6 




n/a 


7 


p= (phone number) 


[39] 6 





n/a 


[39] 6 




n/a 


8 


c= (connection information) 


[39] 6 







[39] 6 






g 


b= (bandwidth information) 


[39] 6 







(NOTE 1 ) 


[39] 6 








Time description (one or more per description) 


10 


t= (time the session is active) 


[39] 6 


m 


m 


[39] 6 


m 


m 


11 


r= (zero or more repeat times) 


[39] 6 





n/a 


[39] 6 




n/a 




Session level description (continued) 


12 


z= (time zone adjustments) 


[39] 6 





n/a 


[39] 6 




n/a 


13 


k= (encryption key) 


[39] 6 







[39] 6 






14 


a= (zero or more session 
attribute lines) 


[39] 6 







[39] 6 








Media description (zero or more per description) 


15 


m= (media name and 
transport address) 


[39] 6 








[39] 6 


m 


m 


16 


1= (media title) 


[39] 6 







[39] 6 






17 


c= (connection information) 


[39] 6 


Cl 


cl 


[39] 6 






18 


b= (bandwidth information) 


[39] 6 







(NOTE 1 ) 


[39] 6 






19 


k= (encryption key) 


[39] 6 







[39] 6 






20 


a= (zero or more media 
attribute lines) 


[39] 6 







[39] 6 






c1: 


IF A.318/15 THEN m ELSE n/a. 














NOTE 1 : 


For "video" and "audio" media types that utilise RTP/RTCP, it shall be specified. For other media types, it 
may be specified. 
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Prerequisite A.3 18/14 OR A.3 18/20 - - a= (zero or more session/media attribute lines) 



Table A.319: zero or more session / media attribute lines (a=) 



Item 


Field 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


category (a=cat) 


[39] 6 






[39] 6 






2 


keywords (a=keywds) 


[39] 6 






[39] 6 






3 


name and version of tool 

(a=tool) 


[39] 6 






[39] 6 






4 


packet time (a=ptime) 


[39] 6 






[39] 6 






5 


maximum packet time 
(a=maxptime) 


[39] 6 






[39] 6 






6 


receive-only mode 
(a=recvonly) 


[39] 6 






[39] 6 






7 


send and receive mode 
(a=sendrecv) 


[39] 6 






[39] 6 






8 


send-only mode (a=sendonly) 


[39] 6 






[39] 6 






9 


whiteboard orientation 
(a=orient) 


[39] 6 






[39] 6 






10 


conference type {a=type) 


[39] 6 






[39] 6 






11 


character set (a=charset) 


[39] 6 






[39] 6 






12 


language tag (a=sdplang) 


[39] 6 






[39] 6 






13 


language tag (a=lang) 


[39] 6 






[39] 6 






14 


frame rate (a=framerate) 


[39] 6 






[39] 6 






15 


quality {a=quality) 


[39] 6 






[39] 6 






16 


format specific parameters 
(a=fmtp) 


[39] 6 






[39] 6 






17 


rtpmap attribute (a=rtpmap) 


[39] 6 






[39] 6 






18 


current-status attribute 

(a=curr) 


[30] 5 


Cl 


cl 


[30] 5 


c2 


c2 


19 


desired-status attribute 
(a=des) 


[30] 5 


Cl 


cl 


[30] 5 


c2 


c2 


20 


confirm-status attribute 
(a=conf) 


[30] 5 


cl 


cl 


[30] 5 


c2 


c2 


21 


media stream identification 

attribute (a=mid) 


[53] 3 


c3 


c3 


[53] 3 


c4 


c4 


22 


group attribute (a=group) 


[53] 4 


c5 


c5 


[53] 3 


c6 


c6 


c1: 


IF A.317/22 THEN o ELSE n/a. 














c2: 


IF A.317/22 THEN m ELSE n/a. 














c3: 


IF A.317/23 THEN o ELSE n/a. 














c4: 


IF A.317/23 THEN m ELSE n/a. 














c5: 


IF A.317/24 THEN o ELSE n/a. 














c6: 


IF A.317/24 THEN m ELSE n/a. 















A.3.2.3 SDP types parameters 

Prerequisite A.3 18/2 - - o= (owner/creator and session identifier) 

Table A.320: owner/creator and session identifier type {o=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


username 


[39] 6 


m 


m 


[39] 6 


m 


n/a 


2 


session id 


[39] 6 


m 


m 


[39] 6 


m 


m 


3 


version 


[39] 6 


m 


m 


[39] 6 


m 


m 


4 


network type 


[39] 6 


m 


m 


[39] 6 


m 


n/a 


5 


address type 


[39] 6 


m 


m 


[39] 6 


m 


n/a 


6 


address 


[39] 6 


m 


m 


[39] 6 


m 


n/a 



Prerequisite A.3 18/10 - - 1= (time the session is active) 
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Table A.321 : time the session is active type (t=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


start time 


[39] 6 


m 


m 


[39] 6 


m 


n/a 


2 


stop time 


[39] 6 


m 


m 


[39] 6 


m 


n/a 



Prerequisite A.318/1 1 - - r= (zero or more repeat times) 



Table A.322: zero or more repeat times (r=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


repeat interval 


[39] 6 




n/a 


[39] 6 




n/a 


2 


active duration 


[39] 6 




n/a 


[39] 6 




n/a 


3 


list of offsets from start-time 


[39] 6 




n/a 


[39] 6 




n/a 



Prerquisite A. 318/12 - - z= (time zone adjustments) 

Table A.323: time zone adjustments type (z=) 



Item 


Field 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


adjustment time 


[39] 6 




n/a 


[39] 6 




n/a 


2 


offset 


[39] 6 




n/a 


[39] 6 




n/a 


3 


adjustment time 


[39] 6 




n/a 


[39] 6 




n/a 


4 


offset 


[39] 6 




n/a 


[39] 6 




n/a 



Prerquisite A.318/1 3 - - k= (encryption key) 

Table A.324: encryption l<ey type (k=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


method 


[39] 6 






[39] 6 






2 


encryption key 


[39] 6 






[39] 6 







Prerequisite A.318/15 - - m= (media name and transport address) 

Table A.325: media name and transport address type (m=) 



Item 


Field 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


media 

"audio" 

"video" 

"application" 

"data" 

"control" 


[39] 6 






[39] 6 






2 


port 


[39] 6 






[39] 6 






3 


transport 


[39] 6 






[39] 6 






4 


fmt list 


[39] 6 






[39] 6 







Editor's note: It is expected that this table will be expanded, as this is the principle table that will distinguish 
operation of different entities within the IM CN subsystem. 
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Prerequisite A.318/17 - - c= (coimection information) 



Table A.326: connection type (c=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


network type 


[39] 6 






[39] 6 






2 


address type 


[39] 6 






[39] 6 






3 


connection address 


[39] 6 






[39] 6 







Prerequisite A.318/18 - - b= (bandwidth information) 



Table A.327: bandwidth information (b=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


modifier 


[39] 6, 

[56] 






(NOTE 1 ) 


[39] 6, 

[56] 






2 


bandwidth-value 


[39] 6 






(NOTE 2) 


[39] 6 






NOTE 1 : For "video" and "audio" media types tiiat utilise RTP/RTCP, tlie value sliall be AS, RR or RS. 
NOTE 2: For "video" and "audio" media types tliat utilise RTP/RTCP, it shall be specified. For other media types, it 
may be specified. 



A.3.2.4 SDP types parameters within attribute lines 

This subclause dos not intend to show an exhaustive list of all the possible attribute values 
Prerequisite A.3 19/22 - - group attribute (a=group) 

Table A.327A: group semantics (a=group) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Lip Synchronization (LS) 


[53] 4 








[53] 4 


m 


m 


2 


Flow Identification (FID) 


[53] 4 








[53] 4 


m 


m 


3 


Single Reservation Flow 

(SRF) 


[54] 2 





m 


[54] 2 


m 


m 



A.3.3 Proxy role 

This subclause contains the ICS proforma tables related to the user role. They need to be completed only for proxy 
implementations. 

Prerequisite: A.2/2 — proxy role 
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A.3.3.1 Major capabilities 



Table A.328: Major capabilities 



Item 


Does the implementation support 


Reference 


RFC Status 


Profile status 




Capabilities within main protocol 




















Extensions 








1 


Integration of resource management 
and SIP? 


[30] 





n/a 


2 


Grouping of media lines 


[531 





c1 


3 


Mapping of Media Streams to Resource 
Reservation Flows 


[54] 





c1 


4 


SDR Bandwidtli Modifiers for RTCP 
Bandwidth 


[56] 





Cl 


c1 : IF A.3/2 THEN m ELSE n/a - - P-CSCF role. 



A.3.3.2 SDP types 

Table A.329: SDP types 



Item 


Type 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 




Session level description 


1 


v= (protocol version) 


[39] 6 


m 


m 


[39] 6 


m 


m 


2 


0= (owner/creator and session 
identifier). 


[39] 6 


m 


m 


[39] 6 






3 


s= (session name) 


[39] 6 


m 


m 


[39] 6 






4 


i= (session information) 


[39] 6 


m 


m 


[39] 6 






5 


u= (URI of description) 


[39] 6 


m 


m 


[39] 6 






6 


e= (email address) 


[391 6 


m 


m 


[39] 8 






7 


p= (phone number) 


[39] 6 


m 


m 


[39] 6 






8 


c= (connection information) 


[39] 6 


m 


m 


[39] 6 






9 


b= (bandwidth information) 


[39] 6 


m 


m 


[39] 6 








Time description (one or more per description) 


10 


t= (time the session is active) 


[39] 6 


m 


m 


[39] 6 






11 


r= (zero or more repeat times) 


[39] 6 


m 


m 


[39] 6 








Session level description (continued) 


12 


z= (time zone adjustments) 


[39] 6 


m 


m 


[39] 6 






13 


k= (encryption key) 


[39] 6 


m 


m 


[39] 6 






14 


a= (zero or more session 
attribute lines) 


[39] 6 


m 


m 


[39] 6 








lUledia description (zero or more per description) 


15 


m= (media name and 
transport address) 


[39] 6 


m 


m 


[39] 6 


m 


m 


16 


i= (media title) 


[39] 6 







[39] 6 






17 


c= (connection information) 


[39] 6 







[39] 6 






18 


b= (bandwidth information) 


[39] 6 







[39] 6 






19 


k= (encryption key) 


[39] 6 







[39] 6 






20 


a= (zero or more media 
attribute lines) 


[39] 6 







[39] 6 
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Prerequisite A.329/14 OR A.329/20 - - a= (zero or more session/media attribute lines) 



Table A.330: zero or more session / media attribute lines (a=) 



Item 


Field 


Sending 


Receiving 






Ret. 


RFC 
Status 


Profile 
status 


Ret. 


RFC 
status 


Profile 
status 


1 


category (a=cat) 


[39] 6 






[39] 6 






2 


keywords (a=keywds) 


[39] 6 






[39] 6 






3 


name and version of tool 

(a=tool) 


[39] 6 






[39] 6 






4 


packet time (a=ptime) 


[39] 6 






[39] 6 






5 


maximum packet time 
(a=maxptime) 


[39] 6 






[39] 6 






6 


receive-only mode 
(a=recvonly) 


[39] 6 






[39] 6 






7 


send and receive mode 
(a=sendrecv) 


[39] 6 






[39] 6 






8 


send-only mode (a=sendonly) 


[39] 6 






[39] 6 






9 


wtiiteboard orientation 
(a=orient) 


[39] 6 






[39] 6 






10 


conference type {a=type) 


[39] 6 






[39] 6 






11 


cliaracter set (a=ctiarset) 


[39] 6 






[39] 6 






12 


language tag (a=sdplang) 


[39] 6 






[39] 6 






13 


language tag (a=lang) 


[39] 6 






[39] 6 






14 


frame rate (a=framerate) 


[39] 6 






[39] 6 






15 


quality {a=quality) 


[39] 6 






[39] 6 






16 


format specific parameters 
(a=fmtp) 


[39] 6 






[39] 6 






17 


rtpmap attribute (a=rtpmap) 


[39] 6 






[39] 6 






18 


current-status attribute 

(a=curr) 


[30] 5 


m 


m 


[30] 5 


c2 


c2 


19 


desired-status attribute 
(a=des) 


[30] 5 


m 


m 


[30] 5 


c2 


c2 


20 


confirm-status attribute 
(a=conf) 


[30] 5 


m 


m 


[30] 5 


c2 


c2 


21 


media stream identification 

attribute (a=mid) 


[53] 3 


c3 


c3 


[53] 3 


c4 


c4 


22 


group attribute (a=group) 


[53] 4 


c5 


c6 


[53] 3 


c5 


c6 


c2: 


IF A.328/1 THEN m ELSE i. 














c3: 


IF A.328/2 THEN o ELSE n/a. 














c4: 


IF A.328/2 THEN m ELSE n/a. 














c5: 


IF A.328/3 THEN o ELSE n/a. 














c6: 


IF A.328/3 THEN m ELSE n/a. 















A.3.3.3 SDP types parameters 

Prerequisite A.329/2 - - o= (owner/creator and session identifier) 

Table A.331 : owner/creator and session identifier type (o=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


username 


[39] 6 


m 


m 


[39] 6 


m 


m 


2 


session id 


[39] 6 


m 


m 


[39] 6 


m 


m 


3 


version 


[39] 6 


m 


m 


[39] 6 


m 


m 


4 


network type 


[39] 6 


m 


m 


[39] 6 


m 


m 


5 


address type 


[39] 6 


m 


m 


[39] 6 


m 


m 


6 


address 


[39] 6 


m 


m 


[39] 6 


m 


m 



Prerequisite A.329/10 - - 1= (time the session is active) 
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Table A.332: time the session is active type (b=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


start time 


[39] 6 






[39] 6 






2 


stop time 


[39] 6 






[39] 6 







Prerequisite A.329/1 1 - - r= (zero or more repeat times) 

Table A.333: zero or more repeat times (r=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


repeat interval 


[39] 6 






[39] 6 






2 


active duration 


[39] 6 






[39] 6 






3 


list of offsets from start-time 


[39] 6 






[39] 6 







Prerequisite A.329/12 - - z= (time zone adjustments) 

Table A.334: time zone adjustments type (z=) 



Item 


Field 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


adjustment time 


[39] 6 






[39] 6 






2 


offset 


[39] 6 






[39] 6 






3 


adjustment time 


[39] 6 






[39] 6 






4 


offset 


[39] 6 






[39] 6 







Prerequisite A.329/1 3 - - k= (encryption key) 

Table A.335: encryption l<ey type (k=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


method 


[39] 6 






[39] 6 






2 


encryption key 


[39] 6 






[39] 6 







Prerequisite A. 329/1 5 - - m= (media name and transport address) 



Table A.336: media name and transport address type (m=) 



Item 


Field 


Sending 


Receiving 






Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


media 

"audio" 

"video" 

"application" 

"data" 

"control" 


[39] 6 






[39] 6 






2 


port 


[39] 6 






[39] 6 






3 


transport 


[39] 6 






[39] 6 






4 


fmt list 


[39] 6 






[39] 6 







Editor's note: It is expected that this table will be expanded, as this is the principle table that will distinguish 
operation of different entities within the IM CN subsystem. 
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Prerequisite A.329/17 - - c= (connection information) 



Table A.337: connection type (c=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
status 


Profile 
status 


1 


network type 


[39] 6 






[39] 6 






2 


address type 


[39] 6 






[39] 6 






3 


connection address 


[39] 6 






[39] 6 







Prerequisite A.329/18 - - b= (bandwidth information) 



Table A.338: bandwidth information (b=) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


modifier 


[39] 6, 
[56] 






[39] 6, 
[56] 






2 


bandwidth-value 


[39] 6 






[39] 6 







A.3.3.4 SDP types parameters within attribute lines 

The subclause does not intend to show an exhaustive list of all the possible attribute values. 
Prerequisite A.330/22 — group attribute (a=group) 

Table A.339: group semantics (a=group) 



Item 


Field 


Sending 


Receiving 


Ref. 


RFC 
Status 


Profile 
status 


Ref. 


RFC 
Status 


Profile 
status 


1 


Lip Synchronization (LS) 


[5314 


m 


m 


[5314 


i 


i 


2 


Flow Identification (FID) 


[53] 4 


m 


m 


[53] 4 


i 


i 


3 


Single Reservation Flow 
(SRF) 


[54] 2 





m 


[54] 2 


m 


m 



A.4 Profile definition for other message bodies as used in 
the present document 

Void. 
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